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ABSTRACT 


As networks grow in complexity and data breaches become more costly, network adminis¬ 
trators need better tools to help design networks that provide service-level availability while 
restricting unauthorized access. Current research, specifically in declarative network man¬ 
agement, has sought to address this problem but fails to bridge the gap between service- 
level requirements and low-level configuration directives. We introduce service-oriented 
access control, an approach that frames the problem in terms of maintaining service-level 
paths between users and applications. We show its use in several scenarios involving tacti¬ 
cal networks typically seen in the military’s field artillery community. 
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CHAPTER 1: 
Introduction 


Computer network complexity continues to grow rapidly. Bridges, routers, firewalls, and 
other network devices flood the marketplace. Each new device provides some new capa¬ 
bility in allowing the network administrator to manage his network. That new capability 
brings the added requirement of configuring the device to ensure proper operation without 
compromising security. Furthermore, proper operation requires proper care and mainte¬ 
nance. A network administrator who is competent and properly trained, therefore, becomes 
even more necessary for meeting these added demands. 

However, as networks change in size and complexity with the introduction of each new 
technology, the task of ensuring service-level availability and access control becomes more 
and more daunting. The tools that today’s network administrator must use to accomplish 
this task are inadequate. At this point in time, the network administrator must rely on 
industry best practices, experience, and trial-and-error methods to design and secure his 
network. 

The discrepancy between the increasing complexity of today’s networks and the network 
administrator’s ability to manage that ability continues to grow. As it grows, the security of 
the world’s sensitive information becomes more and more vulnerable to theft and exploita¬ 
tion. This, in turn, leads to more and more incidents of cyber attack and data loss, costing 
companies, government organizations, and individuals millions of dollars. 

One only needs to read any daily news source to find reports of these incidents. Stories 
of disgruntled students hacking into school servers to change grades are common. Reports 
of data loss by small businesses are seen frequently. Loss of sensitive information by 
large corporations like Target [1] and TJX [2] are becoming more and more common in 
international news. Government organizations like the Department of Veterans Affairs are 
experiencing more and more attempts to exfiltrate sensitive information from their servers. 

Many of these incidents find their causes in networks that are poorly designed or access 
control mechanisms that fail to achieve the organization’s access control policy. Network 
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administrators, despite their best efforts using the tools at their disposal, eannot plug every 
seeurity hole and seeure every service. As networks and their complexity continue to grow, 
best practices and trial-and-error methods cannot meet the increased security requirements, 
and the result is costly. 

Network administrators need proper tools to manage this complexity. They need ways 
to systematically design networks and implement access controls. They should be able 
to specify service-level access control policies and then automatically and systematically 
derive a network configuration that necessarily and sufficiently satisfies those service-level 
requirements. Our research seeks to address this issue. This introductory chapter provides 
some motivation for this issue, defines this problem in more specific terms, and sets the 
stage for our work. 


1.1 Problem Statement 

Ultimately, we seek a solution to the problem that underlies many of the data breaches and 
network attacks mentioned earlier. In order to achieve that solution, we must first state 
the problem in concrete terms. This section presents that problem statement and some 
terminology used throughout this work. 

We specifically describe the aspects of this problem in later chapters, but we provide brief 
definitions here. A physical topology is a description of the physical arrangement of devices 
in a network and the physical connections between those devices. A service specification 
is simply a representation of the services or resources available on a network, as defined 
by their various standards documents. Finally, a logical organization is a description of 
how devices are configured to control the flow of data within the network (e.g. virtual 
local area network (VLAN) configuration, access control list (ACL) placement, or routing 
design). Changing the network’s logical organization affects how data flows in a network 
and therefore affects users’ access to services. 

With these definitions, we state our problem, the service-oriented access control problem, 
as follows. Given a network’s physical topology, a specification of a service that is to run 
on the network, and a policy governing which users have access to the service, output a 
logical organization of the topology, if it exists, that achieves the policy. 


2 



1.2 Research Description 

The main thrust of this research is to design a framework within which the service-oriented 
access control (SOAC) problem can be solved for a limited set of hardware and a limited 
set of possible services. For a given network and service specification, multiple logical 
organizations may exist. It should be understood, then, that the ultimate goal of this re¬ 
search effort, but beyond the scope of this thesis, is to develop an algorithm to compute 
the optimum solution based on some criteria. In this work, our focus is a framework and 
methodology that will allow us to find a solution, if one exists. 

Furthermore, the range of possible devices, services, and configuration options is extensive, 
so our work focuses on a limited set of devices with limited capabilities. Specifically, we 
focus on Internet Protocol (IP) networks with routers that utilize static routing and stateless 
packet filtering, Ethernet switches with media access control (MAC) filtering capabilities, 
and typical hosts and servers. Likewise, the range of network services in existence is vast, 
so we limit our focus to a subset of these services in order to convey the basic concepts 
of the framework. Specifically, we focus on Hypertext Transfer Protocol (HTTP), Secure 
Hypertext Transfer Protocol (HTTPS), and Internet Relay Chat (IRC). We also constrain 
our work in terms of network size. As computer networks can grow quite large, we focus 
our work on small-scale tactical networks like those found in the military’s battalion-sized 
units. 

Notice, however, that the SOAC problem does not have any specific logical organization 
as input. Any algorithm for the problem must produce such an organization and is free to 
explore all possibilities. Therefore, a solution to a SOAC instance may be correct according 
to its service policy but involve network configuration that does not comply with industry 
best practice or human intuition. 

Our work is guided by several research questions. These questions, whose answers are 
discussed throughout this work, are listed below. 

1. Can a network’s logical organization be automatically derived based on its physical 
topology and service requirements? 

2. What constitutes a logical organization? 

3. What constitutes a network service? 
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4. What constitutes a service specification? 

5. How can a network’s logical organization change based on the service specification? 

1.3 Research Benefits 

This study benefits all organizations that rely on computer networks to communicate and 
share information. Each of these organizations has a network of physically connected 
devices and a set of services that must be supported by that network. Therefore, each 
of these organizations finds itself dealing with an instance of the SOAC problem. 

This study benefits the Department of Defense (DOD) in particular because the data and 
services on its networks are particularly sensitive. The national security of the nation heav¬ 
ily depends of the security of the networks maintained by the DOD. Therefore, the need 
for tools that aid in secure network construction is critical. This work helps meet that need 
and helps ensure the security of the nation’s secrets. 

1.4 Organization 

Chapter 2 provides background information on this research topic. Several sections de¬ 
scribe the current state of research in this area and how previous work contributes to our 
research. This chapter also provides motivation for our approach to the problem. 

Chapter 3 details the model that we use to frame the problem. It introduces abstractions for 
the network’s physical topology, abstractions for the corresponding logical organization, 
and an operational semantics to describe network behavior. 

Chapter 4 describes the design of our access control logic used to reason about denying 
access to network resources. 

Chapter 5 shows how we can use the SOAC approach to configure a common tactical 
network. Three scenarios show the application of the framework on tactical networks seen 
in United States Marine Corps (USMC) field artillery battalions. 

Chapter 6 includes our conclusion of the research and recommendations for future work. 
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CHAPTER 2: 
Related Work 


Efforts have been made to ease the burden of network management. What these efforts 
have in common is a way to specify a particular logical organization in a high-level lan¬ 
guage that is then reasoned about for properties like conflicts, reachability, black holes, 
etc. and ultimately translated automatically into low-level device configuration commands. 
Contrast this with SOAC. It does not include any logical organization as input. A solution 
to SOAC is a logical organization. For this reason, SOAC is similar to the problem of 
zero-configuration networking (Zeroconf) except the latter does not include a service de¬ 
scription as input. Zeroconf merely tries to establish local-area connectivity and a name 
space. 

We contrast earlier efforts in network management and Zeroconf with SOAC in more detail 
in the following sections. In Section 2.1, we survey the fields of network management and 
network design, relating various works to SOAC. In Section 2.2, we introduce Zeroconf and 
explain the fundamental assumption that separates Zeroconf and SOAC. In Section 2.3, we 
investigate static reachability analysis and its relation to our work. As we will see, SOAC 
is a problem that is much different from the problems addressed by declarative network 
management and zero-configuration networking. 

2.1 Network Management and Design 

The field of current network management research that most closely relates to our work 
is declarative network management. This research aims to ease the task of network man¬ 
agement by allowing the network administrator to specify network policy in a declarative 
manner, typically using relational logic. With a declarative network management approach, 
the network administrator expresses what properties must be present in the network. Vari¬ 
ous mechanisms and engines take that policy and convert it into lower-level configuration 
directives to implement that policy in the network. 

Narain et al. [3] present a declarative network management system based on model find¬ 
ing. Motivated by the large gap between end-to-end infrastructure requirements and de- 
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tailed implementations, they offer a solution for four fundamental problems in network 
management: network requirement specification, configuration synthesis, configuration er¬ 
ror diagnosis, and configuration error repair. They express configuration information as a 
database containing variables and configuration requirements as constraints on those vari¬ 
ables. These requirements typically describe desired subnetting or IP address allocation. 
The key to the system, therefore, is a requirement solver that takes a database and a set of 
requirements as inputs and tries to compute values for the variables that satisfy the require¬ 
ments. The requirement solver uses a model finder to convert requirements expressed as 
first-order logic into Boolean constraints that serve as inputs for a SAT solver. The SAT 
solver provides either a solution or a proof of unsolvability. 

This work also addresses several issues relevant to our discussion. The motivation for the 
work of Narain et al. [3] lies in the large gap between high-level infrastructure requirements 
and the low-level configuration directives that meet those requirements. We notice a trend 
in the design of these network management systems. Some collection of variables and 
values make up the configuration space. Some knowledge base of network behavior is 
captured in a systematic manner. Some set of requirements or desired outcomes, specified 
in terms of the knowledge base, is provided. Finally, some engine instantiates or constrains 
the variables based on the knowledge base and desired outcomes. However, the system 
described by Narain et al. contains a knowledge base that only expresses knowledge of 
the network. For example, they describe several requirements about IP addresses in the 
network, including the requirement for unique IP addresses for hosts on the same subnet. 
It does not justify these requirements in terms of granting or denying access to services. 
Furthermore, we cannot tell how failure to meet the requirement affects the service. An 
instance of SOAC includes a service specification and establishes a relationship between 
the network and its services, hence the service-oriented nature of the problem. 

Hinrichs et al. [4] provide an approach to network management using a declarative lan¬ 
guage to specify policy and specialized network hardware to implement that policy in 
the network. Motivated again by the inadequacy of traditional network configuration 
techniques, the authors present Flow-based Management Language (FML), a flow-based 
declarative network policy language. This language allows a network administrator to spec¬ 
ify a rule containing several characteristics of a network flow - including source and target 
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users, source and target hosts, and source and target access points - and whether that flow 
should be allowed, denied, or relegated to a certain path in the network. A security policy, 
therefore, is a list of rules enforced in the network. The authors provide several examples 
of policies for various uses, including access control, network address translation (NAT), 
and quality of service (QoS). The authors implement this language within NOX [5], an 
operating system for OpenFlow [6] controllers, and deploy policies specified in FML on 
networks consisting of a series of OpenFlow switches. 

This work provides some interesting insight and some potential overlap with a SOAC 
approach. The authors [4] describe flows in terms of users, hosts, access points, and 
protocols. FML ties flows to the network in two ways. First, for each flow, the 
policy writer specifies source and destination access points. In the policy statements 
allow{Us,Hs,As,Ut,Ht,At,Prot,Req) and deny{Us,Hs,As,Ut,Ht,Aj,Prot,Req), A^ and Af 
are network access points. Specifying these access points effectively ties flows to network 
elements besides source and destination hosts. Second, the policy writer specifies network 
nodes through which flows are specifically routed (with the waypoint keyword) or through 
which flows are specifically not routed (with the avoid keyword). SOAC requires that we 
focus simply on users and services. We should consider the network a “black box”, where 
we are not necessarily concerned with the details of the network configuration as long as it 
is correct with respect to the service-level requirements. We are not necessarily concerned 
with routing of flows through a network as long as the service-level goals are met. 

Chen et al. [7] present a database-driven declarative system for network management and 
operation. This system’s design is motivated by the increasingly complex task of network 
management, by the difficulty of network-wide reasoning, and by the dynamic nature of 
networks. The authors’ key observation about the state of affairs in network management 
is that a systematic expression of domain knowledge (i.e., relationships between various 
network protocols and between protocols and the network devices that support them). Their 
system, therefore, captures this knowledge and exposes high-level primitives to simplify 
and automate both device-specific and network-wide management while minimizing the 
need for human intervention. The building blocks of this system include a data model that 
stores network device configuration and status, a set of rules representing the previously 
mentioned domain knowledge, and an engine that leverages the data and ruleset to provide 
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database-like operations like data queries, insertions, and deletions. Rules, as described 
in the paper, typically describe how some high-level network behavior depends on lower- 
level network or device configuration. The resulting capabilities, therefore, are network¬ 
wide reasoning, automatic configuration (given the ability to write configuration data), and 
network policy enforcement. 

This work seems to address many of the issues that we pose in our introductory discussion. 
Chen at. al. [7] share our motivation that networks are growing in complexity and that tools 
available to network administrators today fail to manage that complexity. They also identify 
the lack of a systematic description of network behavior as a major factor in the discrep¬ 
ancy. They also seek to provide high-level primitives and abstractions to simplify the task of 
describing network properties. For example, they simplify the task of configuring a Virtual 
Private LAN Service (VPLS) connection, which is difficult when performed manually, with 
the single database query ActiveVPLSConnection. insert (intl_id,int2_id). This 
approach focuses on providing high-level network abstractions for network administrators 
to use in realizing network policy. Though these higher-level abstractions are useful, the 
focus here is the expression of network policy. In SOAC, we need an approach that focuses 
on users and their access to services. Network organization and relationships between net¬ 
work elements should not be taken as input but rather generated as a part of a solution to a 
SOAC instance. 

Several other works [8]-[ll] in the field fit within the same basic framework. One of 
the common themes in this research is that a network administrator specifies a network 
policy, usually expressed in terms of network elements or relationships between network 
elements. For example, FML requires a policy writer to define a flow by specifying users, 
hosts, access points, protocol, and whether only requests should be considered. In order to 
specify the access points, the writer must have some understanding of how access points 
and hosts relate to each other in the network. When considering the SOAC problem, these 
approaches seem to fall short because they tie high-level policy to the network. A SOAC 
instance requires a policy governing which users have access to which services, without 
reference to underlying network elements. 

With this understanding, the fundamental difference between declarative network manage¬ 
ment and SOAC lies in the inputs of the two problems. A SOAC instance does not include 
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a policy regarding flows, like FML, or relationships between network elements, like Narain 
et al. Instead, the only sort of poliey input to a SOAC instanee is a serviee aeeess poliey 
governing whieh users may or may not aeeess a given serviee. A deelarative network man¬ 
agement approaeh entails expressing a poliey that the network must be eonfigured a eertain 
way, algorithmieally deriving that eonfiguration, and then using experienee and industry 
best praetiees to justify why that poliey aehieves the required aeeess eontrol. This gap 
between network poliey and serviee-level requirements motivates our work. We seek an 
approaeh that is more rigorous and eomplete than relying on experienee and industry best 
praetiees. 

Departing from deelarative network management. Sung et al. [12] foeus on network de¬ 
sign in enterprise networks. They share our motivation of simplifying the task of network 
management, and they speeifieally look at the unique ehallenges of designing enterprise 
networks (i.e. the need for highly eustomized designs with wider ranges of seeurity, re- 
silienee, and performanee requirements). They deeompose the task of enterprise network 
design into four steps: (1) physieal topology planning, (2) VLAN and link-layer design, 
(3) routing design, and (4) reaehability eontrol. In this work, they address VLAN design 
and reaehability eontrol and propose systems for aeeomplishing eaeh. For VLAN design, 
a system takes as input a mapping of hosts to organizational groups and a table of traffie 
patterns, in kilobits per seeond, between groups. It outputs VLAN assignments for hosts 
and plaeement of designated router and root bridge for eaeh VLAN, all sueh that traffie 
cost is minimized. Sung et al. define this eost as the sum of broadeast traffie, inter-VLAN 
data traffie, and intra-VLAN data traffie. For reaehability eontrol, a system takes as input 
a reaehability matrix between VLANs and a set of topology-ehanging events to whieh the 
network must respond while meeting all requirements in the reaehability matrix. It outputs 
reeommended ACL placement based on both eorreetness and feasibility eriteria. Multiple 
solutions for ACL plaeement may meet eorreetness and feasibility eriteria, so the designer 
ehooses one of four placement strategies based on preferenee. Sung et al. evaluate this ap¬ 
proaeh by applying it to a large-seale eampus network topology and eomparing broadeast 
traffie, data traffie, and ACL eorreetness between the eurrently running network and the 
systematie design. They also used systematic ACL placement to diseover an ineonsisteney 
in aeeess eontrol on the eurrently running network. 
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Concerning SOAC and this thesis, this paper [12] provides several points of discussion. 
First, the reachability matrix, originally proposed in previous work [13] and applied here, 
closely resembles the notion of a service policy that a SOAC instance takes as input. In the 
reachability matrix Mr, traffic permitted from VLAN i to VLAN j is denoted by MR{i,j) 
and is expressed as a set of packets whose header information meet certain criteria given 
in first-order logic. Expressing reachability in terms of traffic between VLANs does not 
match our intent to express a service policy only in terms of users and their access to ser¬ 
vices. However, we could adapt the reachability matrix to capture application-layer mes¬ 
sages allowed (or not allowed) between hosts, which better suits our purposes. Second, 
Sung et al. propose four strategies used as preferences for ACL placement that is certainly 
useful in SOAC. They observe that multiple solutions for ACL placement may exist and 
that some strategy for choosing the best solution should be employed. In the same way, 
multiple solutions may exist for a SOAC instance, so some strategy for choosing the best 
solution should be employed. Third, the size of networks addressed by Sung et al. is much 
larger than those addressed in this thesis. Whereas we consider small-scale networks like 
those supporting battalion-sized units, they focus on large-scale enterprise networks con¬ 
sisting of thousands of hosts and hundreds of routers and switches. Despite the difference in 
scale, this work is still relevant specifically in its discussion of systematic reachability con¬ 
trol and its heuristics for ACL placement, as mentioned earlier. However, it is constrained 
to achieving access control through VLAN assignment and ACL placement. Sung et al. 
show how this approach mirrors the most common practice in enterprise network design. 
Nonetheless, we seek an approach that allows us to utilize the entire logical organization 
space to determine a solution. A solution to a SOAC instance may involve VLAN assign¬ 
ment and ACL placement, but such tasks are not necessary. An equally correct solution 
may not involve either of these practices. 


2.2 Zero-Configuration Networking 

The field of Zeroconf takes a unique approach to taking the guesswork and human inter¬ 
vention out of network design and administration. The uniqueness of Zeroconf lies in its 
ultimate goal. The initial requirements document [14] describes this goal, where network 
hosts automate the task of network configuration. In home networks, mobile networks, 
ad hoc networks, and other emerging networks, there may not be adequate personnel or 
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knowledge available to administer the network properly. Therefore, Zeroconf seeks au¬ 
tomatic configuration of networks without manual intervention or central administration. 
Though originally conceived as a solution in smaller ad hoc networks, some research efforts 
seek to extend this functionality to larger networks, including enterprise networks. 

Zeroconf is a collection of complementary network protocols that, when employed on a 
network of devices with connectivity at the data link layer, accomplish four specific tasks 
required to enable networked applications to communicate over an IP network. Those four 
tasks, as specified in a host profile [15], are listed below. 

1. IP interface configuration 

2. Translation between host name and IP address 

3. IP multicast address allocation 

4. Service discovery 

A Zeroconf implementation is essentially a suite of protocols that collectively accomplish 
these tasks. For example, popular Zeroconf implementation, Apple Bonjour [16], imple¬ 
ments Internet Protocol Version 4 Link-Local Addressing (IPv4LL) [17] for interface con¬ 
figuration, Multicast DNS (mDNS) [18] for host name resolution, and DNS-based Service 
Discovery (DNS-SD) [19] for service discovery. In this protocol, a service provider adver¬ 
tises a service that is accessible to any other host that understands the protocol. Bonjour 
does not specifically address multicast address allocation. These three protocols work to¬ 
gether to achieve the goal of automatic network configuration for supporting services and 
networked applications. 

Early Zeroconf implementations accommodated small single-router ad hoc networks (e.g., 
a home local area network (LAN)). Some research efforts seek to extend this functional¬ 
ity to larger multi-router networks. Single-router Zeroconf solutions do not address some 
issues associated with multi-router networks. Specifically, single-router solutions fail to 
provide dynamic exchange of routing information between routers and consistent assign¬ 
ment of IP subnets in the network. These issues motivate recent work in the field. Akinlar 
et al. [20], [21] present algorithms to address these issues in multi-router networks. With 
these issues addressed, Zeroconf implementations can ensure IP connectivity between all 
hosts in a multi-router network and can therefore facilitate operation of the higher-level host 
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name resolution and service discovery protocols throughout the network. Therefore, they 
can enable automatic configuration and service discovery in larger networks like tactical 
and small organizational networks. 

Fundamentally, Zeroconf addresses the need to enable communication without manual in¬ 
tervention or central administration. Because of the lack of central administration, there¬ 
fore, individual hosts are responsible for controlling access to their services. However, the 
only access control mechanism available to hosts is not advertising services. This lack of 
fine-grained security control is simply unacceptable in most use cases, even in home net¬ 
works where certain family members like children may not access certain services. SOAC 
assumes that a central administration authority is available to provide a service specifi¬ 
cation. Therefore, a SOAC approach enables that authority to implement a fine-grained 
access control scheme for the network’s resources that Zeroconf simply cannot provide. 

Furthermore, a major difference between a Zeroconf approach and SOAC lies in what 
network properties are configured. As previously stated, a specific protocol focuses on 
unique IP address and subnet assignment among devices. Once it achieves this, host name 
resolution and service discovery protocols allow service-level communication. The only 
network configuration that occurs in this process is assignment of IP addresses. Though 
this may be enough to enforce a security policy in some cases, we see the need to leverage 
as many configuration options as possible in order to achieve the fine-grained security needs 
of tactical and organizational network administrators. 

2.3 Static Reachability Analysis 

Static reachability analysis is about analyzing a description of a network’s logical organi¬ 
zation to determine whether the organization admits packets between given hosts. Xie et 
al. [13] introduce the notion of static analysis for determining reachability across a net¬ 
work, and they outline several advantages of the approach. First, static analysis allows a 
network administrator to compute all possible packets that could travel from a given source 
to a given destination. Second, static analysis allows a network administrator to compute 
all possible paths that a given packet could take and, therefore, all possible destinations 
that a given packet at a given location could reach. Third, static analysis mitigates risk 
by allowing analysis before network deployment and before a problem arises. Fourth, a 
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network designer ean use statie analysis to determine whether a network’s implementation 
(i.e. low-level eonfiguration) meets the designer’s intent. 

Xie et al. [13] deseribe how to eompute reaehability in a network using statie analysis of 
router eonfiguration files. They model a network as a graph G = where V is 

the set of routers, E is the set of direeted edges defining eonneetivity between routers, and 
is a funetion that annotates edges in E sueh that, for eaeh edge (m,v) G E, E^^v ^ 
is the set of paekets that the network ean earry from u to v. is also expressed as 
a paeket filter fu,v containing predicates that test properties of packet p, returning true if 
p G v This enables reasoning about packet flow over multiple routers by simply applying 
set operations and first-order logic. For example, determining the set of packets allowed 
from router u through router v to router w is done taking the intersection y H Fy^vv or 
by determining the conjunction /„^y A Furthermore, forwarding state (i.e. collective 
contents of each router’s forwarding table) influences reachability, so they define Eu^s) as 
a function mapping the network’s forwarding state s to the set of packets allowed from u 
to V when the network is in state s. With these primitives, Xie et al. show how to compute 
network-wide reachability bounds using classical graph algorithms. 

More recent work in this area extends static reachability analysis in various ways. Feam- 
ster and Balakrishnan [22] use static analysis to detect Border Gateway Protocol (BGP) 
configuration faults. Mai et al. [23] cast static analysis Kazemian et al. [24] introduce 
a protocol-agnostic framework that statically analyzes network device configurations to 
identify reachability failures, forwarding loops, traffic isolation, and leakage problems. 

In terms of inputs and outputs, however, these works address a common problem. This 
problem takes as input some representation of a network’s physical topology and logi¬ 
cal organization, usually in the form of router configuration files. It outputs information 
about useful network-wide properties, like reachability or configuration consistency. From 
this perspective, static reachability analysis fundamentally differs from SOAC. Whereas 
static analysis takes configuration as input and provides network-wide properties as out¬ 
put, SOAC requires network-wide requirements, in the form of users and their access to 
services, as input and provides configuration as output. 
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CHAPTER 3: 
Network Model 


A TCP/IP network is a complex system. It consists of devices that communicate with each 
other through interfaces using a set of complex communications protocols. It is possible, 
however, to reduce this complex set of protocols and vast range of configuration parameters 
into concepts that are both simple to understand and relevant to a specific set of network 
properties. For reasoning about network access control (i.e., developing a formal logical 
method for ensuring controlled access to network resources), much of this complexity be¬ 
comes unnecessary. Therefore, an important step toward achieving the formal method is 
developing a model that eliminates as much complexity as possible without losing infor¬ 
mation needed to reason about the properties in a real network. For example, it would be 
unsatisfactory to model network performance without considering link-layer protocols for 
resolving contention if multiple users share a network link. 

In this work, we sought to build a rudimentary framework for approaching the issues asso¬ 
ciated with service-oriented access control. Therefore, we focused on developing a model 
that eliminates unnecessary complexity and simplifies the task of reasoning about service 
oriented access control. We also focused on capturing the basic operation of the network 
rather than one that tackles all possible features and capabilities used to achieve an ac¬ 
cess control strategy. However, we kept a high level of granularity that enables reasoning 
not only about a datagram’s movement between devices in the network but also about its 
movement between layers of the network stack. 

To this end, we developed a model employing several abstractions that we describe in this 
chapter. Section 3.1 describes the network’s physical topology and how it is represented. 
Section 3.2 describes the network’s logical organization, how it is represented, and how it 
relates to the physical topology. Finally, Section 3.3 describes abstractions used to model 
the network’s behavior, specifically abstractions to represent datagrams and to describe 
how they are transported across the network. 
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3.1 Physical Topology 

A network’s physical topology is one of the inputs to this problem. Therefore, it is im¬ 
portant that we capture all necessary information about a network’s physical topology in 
a manner that facilitates reasoning about access control within the network. To this end, 
we designed a structured mapping to organize and label this information to support our 
approach. 

We organize this information into a mapping of devices and interfaces to their unique at¬ 
tributes. For example, the mapping D represents a network and provides information about 
the network’s devices, interfaces, and connectivity. Each device in D is uniquely named, 
so for a device m on the network, (D m) provides information and attributes unique to m. 
This allows us to reference attributes unique to m within D. 

Though a physical topology can be extremely complex and detailed, we are only concerned 
with the necessary pieces of information needed for our purposes. These necessary pieces 
of information are described in this section. We begin by introducing the notion of a de¬ 
vice’s type. We then show how a device’s network interfaces are named and organized. 
We then show how we capture direct connectivity between interfaces. Finally, we describe 
how we capture hardware-level addresses. 


3.1.1 Device Type 

If D represents a network, and m names a device in the network, then {Dm).type is a set of 
labels that indicate the type of m. The device’s type corresponds with its basic functionality 
and capabilities. For example, an IP router is generally capable of receiving an IP packet 
at one interface and forwarding it to another interface on the device for transmission based 
on the longest matching network prefix of the packet’s destination IP address [25], [26]. 
Therefore, if the device m is of type router, or if router G {Dm).type, then m has this IP 
routing capability within the model. 

In this work, we considered clients (which we called hosts), IP routers, servers, Eth¬ 
ernet switches. Therefore, {Da).type C {host,router,server,switch} for every device 
a G domain{D). IP routers have the packet forwarding capability described above as well 
as stateless ingress packet filtering and egress packet filtering on all interfaces. Servers gen- 
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erally listen for incoming requests and have similar ingress and egress filtering capabilities. 
Ethernet switches [27] can forward Ethernet frames and have ingress and egress filtering 
capabilities based on MAC address. A device may have more than one type. Eor example, a 
device may act as a server providing one service while acting as a client requesting another 
service. 

3.1.2 Network Interfaces 

Each device connects to and communicates with the network through at least one net¬ 
work interface. In many cases, devices communicate through several interfaces. Ethernet 
switches, for example, may contain 24 or more network interfaces. Each interface contains 
some unique attributes that must be captured. 

Eor a device m, {Dm).if aces is a set of the names of all interfaces on the device. Each 
interface is uniquely named, so if interface u is on device m, then u G {Dm).if aces. Eur- 
thermore, an interface can be uniquely referenced in order to preserve the interface’s unique 
attributes. Information about u can be referenced by using the notation {Dm).ifaces[u]. 

3.1.3 Direct Connections 

Eor the interface u on m, {Dm).ifaces[u\.direct provides information about its directly 
connected interfaces. This attribute is a set of names of all interfaces that have direct 
physical-layer connectivity with u. By direct connectivity, we mean that connections are 
established such that link-layer communication is possible. In an Ethernet network, for 
example, {Dm).ifaces[u].direct = {v} if u is connected to interface v on device n via an 
Ethernet cable and if u can send an Ethernet frame to v. However, v is not necessarily able 
to send a frame to m; we would have to say that {Dn).ifaces[v].direct = {m} in order to 
capture such a symmetric connection. 

Because of (1) the ability to capture a one-to-many relationship between connected in¬ 
terfaces and (2) the ability to capture asymmetric physical connections, this model can 
represent wireless networks as well as wired networks. Though we do not explore wireless 
networks specifically in this work, the model could be easily extended to allow for this. 
If we have a wireless local area network (WEAN) [28] interface w that can communicate 
with interfaces x, y, and z, then {Dq).ifaces[w].direct = {x,y,z}. 
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3.1.4 MAC Address 

For every network interface on every interface, except those interfaces belonging to an Eth¬ 
ernet switch, we require a hardware-level address, or MAC address, that uniquely identifies 
that interface on the network segment. {Dm).ifaces[u].hwaddr provides this address for 
interface u. We consider this attribute to be part of the physical topology of the network, 
and therefore part of our problem’s input, because an interface’s MAC address is most 
commonly set within the interface’s firmware. 

We do not specify a format for this attribute. Though we only considered the ubiquitous 
48-bit MAC address format specified in most Institute for Electrical and Electronics Engi¬ 
neers (IEEE) 802 standards, the model remains format-independent. Throughout this work, 
we represent 48-bit MAC addresses as six bytes, each written as two hexadecimal digits, 
separated by colons. Eor example, {Dm).ifaces[u\.hwaddr = 45:09:ED:3A:01:BB. 


3.2 Logical Organization 

We capture information about the network’s logical organization in the same way we cap¬ 
ture information about its physical topology. In addition to physical characteristics like 
MAC addresses and direct connections, the mapping of devices and interfaces to their 
unique attributes also includes attributes configurable by network administrators. We orga¬ 
nize the attributes of a network’s logical organization just as we organize attributes of its 
physical topology. 

In a network represented by the mapping D, {Dm).ifaces[u] provides logical information 
like IP address for the interface u on device m just like it provides physical information 
like MAC address. In this section, we describe how we capture pertinent information about 
a network’s logical organization, specifically how we represent IP addresses and subnet 
masks, forwarding table entries, and packet filter information. 

In this thesis, logical organization is assumed not to be a function of dynamic events like 
link or device failure. Eogical organization affects access control, and an enterprise network 
running spanning tree algorithms would preserve access control in response to link failures. 
However, there are cases where organization is a function of failure. An example is a route 
that changes based on an interior or exterior gateway routing protocol. An algorithm for 
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SOAC assumes it has the final say in all routing, and therefore if there are any physieal 
ehanges to network topology then the algorithm must be re-run to get a new organization. 

3.2.1 IP Address and Subnet Mask 

{Dm).ifaces[u\.ipaddr provides the network-level address, or IP address, for the interface 
u on device m in network D. We consider the IP address to be part of the network’s logical 
organization because, unlike the MAC address, the IP address of an interface is most com¬ 
monly set by the device’s operating system (or by a user with administrative rights on the 
device). 

Likewise, {Dm).ifaces[u\.netmask provides the interface’s subnet mask. This attribute is 
closely related to the IP address, is also commonly set within the device’s operating system 
settings, and is therefore included as a part of the network’s logical organization. 

Because of its ubiquity at the time of this work, we use the addressing scheme specified by 
IP version 4 [29] in this model, and we use ipaddr to label this attribute. In this work, we 
represent IP addresses in dotted decimal form (i.e., as four bytes) with each byte written 
as a decimal number from zero to 255, separated by dots. However, it would be possible 
to adapt this model to accommodate other layer 3 logical addressing schemes. Since the 
IP address and subnet mask, therefore, are ultimately strings of 32 bits, common bitwise 
operations can be performed on them. In this work, we use the bitwise AND operation 
(represented as the & symbol), the bitwise OR operation (represented by the | symbol), 
and the bitwise negation or one’s complement (represented by the -i symbol) as operations 
on these attributes. 

3.2.2 Forwarding Table Entries 

IP routers generally contain some sort of table structure containing a mapping of networks 
to interfaces. They use this table to properly route packets to their destination. Therefore, 
the information in this table is an important part of a network’s logical organization. Be¬ 
cause this table relates networks to interfaces, we capture the information in this forwarding 
table in an attribute at each interface. For an interface u on device m, {Dm).ifaces[u].dest 
is an address governing which packets will be forwarded out interface u upon arriving at 
other interfaces of m. This attribute follows the same format as the IP address and the 
subnet mask. The bitwise operations mentioned earlier also apply to this attribute. 
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3.2.3 Ingress/Egress Filters 

Packet filters are an integral part of a network’s logical organization and access control 
policy. In this work, we consider the use of stateless ingress and egress packet filtering as 
part of an access control policy. This sort of filtering ability is common in most modern 
operating systems. 

If u names an interface on device m in network D, then {Dm).ifaces[u\.ifilter is a func¬ 
tion mapping a header field to a set of values used in filtering incoming packets. Like¬ 
wise, {Dm).ifaces[u].efilter is a function mapping a header field to a set of values used 
in filtering outgoing packets. For example, {Dm).ifaces[u].ifilter[dstip] is a set contain¬ 
ing all IP addresses that, if matched to a packet’s destination IP address, will cause that 
packet to be discarded. More formally, a packet p is filtered at interface u if p.dstip G 
{Dm).ifaces[u\.ifilter[dstip\. We may also write p.dstip ^ {Dm).ifaces[u\.ifilter[dstip] 
to explicitly state that p will not be filtered. In addition to dstip, we use the field srcip for 
source IP address filtering. 

We also use srcport and dstport for filtering on transport-layer segments. In these fil¬ 
ter sets, however, we also include the transport-layer protocol in the set to differentiate 
between popular transport-layer protocols like Transmission Control Protocol (TCP) and 
User Datagram Protocol (UDP). For example, we block transport-layer segments destined 
for TCP port 80 with the statement {tcp, 80) G {Drn).ifaces[u\.ifilter[dstport\. 

In addition to packet filters at the network and transport layer, filtering at the link layer 
based on MAC address is also a common ability. Not only can we expect most modern 
operating systems to be able to filter based on MAC address information, but we can also 
expect switches to filter based on this information. Therefore, we use the sets srchw and 
dsthw for this MAC filtering. Similar to packet filtering, we block a frame / based on 
source MAC address by stating that f .srchw G {Dm).ifaces[u].ifilter[srchw]. 

3.2.4 Transport-Layer Port Range 

(Dm) .portrange specifies the set of valid transport-layer port numbers on a device m in net¬ 
work D. Based on TCP [30] and UDP [31] specifications, port numbers are 16-bit fields that 
each correspond with 65,536 possible ports on an interface. Therefore, {Dm).portrange 
typically consists of these 65,536 different port numbers. Though this set is not typically 
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part of a network’s logical organization, we use it in the network semantics, which is de¬ 
scribed later, to capture a client’s ability to assign a random valid port number to an outgo¬ 
ing transport-layer segment. 

3.3 Network Behavior 

With network access control, we are concerned with controlling the flow of messages 
throughout the network. If we want to control access to a particular server, then we should 
focus on controlling traffic to and from that server. In order to do that, however, our model 
must allow us to reason the logical organization influences that traffic. Furthermore, the 
model must be simple enough to allow us to focus on the task of reasoning about access 
control. 

In general, our model achieves this by casting network behavior in terms of translating, 
or rewriting, values between variables. A value corresponds with a datagram, also known 
as a protocol data unit (PDU). The variables that can hold these values correspond with 
network interfaces. These values are rewritten between variables according to the network 
semantics. This section describes this model of network behavior in detail by describing the 
datagram abstractions used as values, the network interface abstractions that take the form 
of variables, and the network semantics that describes how translations of values between 
these variables can occur. 

3.3.1 Protocol Data Unit Values 

Protocol data units (e.g., Ethernet frames, IP packets, and TCP segments) are represented 
as values that can be assigned to variables and rewritten between variables. A value is a 
string that serves as a simple representation of a PDU. It consists of information contained 
in a datagram that is pertinent to access control. The following pseudo-grammar specifies 
the values used in this thesis: 

A ::= HTTP_RQ | HTTP_RS | HTTPS_RQ | HTTPS_RS | IRC_PRIVMSG 

S ::= {protocol,srcportjdstport,A) 

P ::= {srcip,dstip,S) \ {srcip,dstip,\Cy\P) 

F ::= {srchw,dsthw,P) \ {srchw,dsthw, ARP) 
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The set A contains all application-layer messages. Though this set can be extensive, it is 
confined to the values described above to help illustrate the basic concepts proposed in 
this work. The set 5 contains all transport-layer segments, so the value 5 can represent a 
segment, where 5 G 5. Likewise, P contains all network-layer packets, so p G P represents a 
packet. Finally, F contains all link-layer frames, so / G F refers to a single frame. Header 
information is represented using dot notation. For example, an IP packet p G F has a 
header with a source IP address p.srcip = 10.0.0.1 and a destination IP address p.dstip = 
10.0.0.100. Encapsulated data is represented in a similar way. The packet p encapsulates a 
TCP segment 5 G 5, so p.data = 5 . Likewise, an Ethernet frame / encapsulates p such that 
f.data = p. 

3.3.2 Interface Variables 

Our model is built on assumptions that the network consists of several devices, each with 
one of more network interfaces, and that each of those interfaces is directly connected to 
one or more distinct interfaces via the physical layer. With this assumption, we can say 
that each interface in the network is uniquely named and has two variables associated with 
it: an ingress variable and an egress variable. A network interface v has an associated 
ingress variable v, and an associated egress variable Vg. Each variable can hold a value as 
previously described. 

Therefore, we can specify a notation for showing rewrites of values between variables using 
the rewrite operation. Consider an example where we wish to show a rewrite of a packet 
p from the egress variable associated with interface u to the ingress variable associated 
with interface v. We formally represent this with {p,Ue) —)■ (pAi)- Likewise, we show 
encapsulation of a packet p within a frame / by the rewrite {p,Ue) —)■ (/, Ug). 

3.3.3 Network Semantics 

We use a system of inference rules to codify commonly accepted network behavior (as 
specified by Internet Engineering Task Eorce (lETE) requests for comment, IEEE stan¬ 
dards, and other standards documents) as translations of values between variables. A 
standards-based semantics for an IP network over Ethernet with the simplicity and granular¬ 
ity required for our framework is given in a whitepaper [32] and reproduced in Appendix A. 
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By exploiting the transitive properties of the semantics, the system allows us to take service- 
level availability requirements and determine constraints on the network to realize those 
requirements and prove their availability. For example, the following rule captures require¬ 
ments for frame transmission from an arbitrary device m to a non-switch device n: 

switch ^ ipn).type 

feF 

y G {Dm).ifaces[w].direct 
m^n 

f.dsthw = {Dn).ifaces[y].hwaddr 
f.srchw ^ {Dn).ifaces[y].ifilter[srchw] 
f.dsthw ^ {Dn).ifaces[y\.ifilter[dsthw\ 

D^{f,we) {f,yi) 

The transmission is represented as a translation of frame / at variable Wg to variable y,, 
where w is an interface of m and y an interface of n. In order for this to occur, y must be 
directly connected to w via the physical layer, the destination hardware address of / must 
match the hardware address of y, and the frame must not be blocked by an ingress filter 
at y. Those requirements are expressed in the antecedents of the rule above the horizontal 
line. Below the line is the conclusion that, with respect to the network D, frame / at egress 
variable Wg can be rewritten as a frame at ingress variable y,- provided the conditions in the 
antecedent of the rule are satisfied. 

Note that this rule is actually a rule scheme because ifilter is unspecified. A con¬ 
crete definition of ifilter produces a concrete semantics. Say, for example, we have 
{Dn).ifaces\y].ifilter instantiated such that the following is true: 

45:09:ED:3A:01:BB G {Dn).ifaces\y\.ifilter[srchw] 

Therefore, the concrete semantics would prescribe that rewrites are impossible between 
these two interfaces for frames having this source hardware address. 

To further explain the how the network semantics captures knowledge of network behavior, 
we contrast the previously mentioned rule, named (frame-tx-rx), with a rule that cap- 
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tures requirements for frame transmission from an arbitrary device m to a switch labeled n. 
This rule, named (frame-tx-switch-rx), is listed below: 

switch G ipn).type 

feF 

y G {Dm).ifaces[w].direct 
m^n 

f.srchw ^ {Dn).ifaces[y].ifilter[srchw] 
f.dsthw ^ {Dn).ifaces[y\.ifilter[dsthw\ 

D^{f,we) {f,yi) 

Notice here that (1) the stated conclusion is the same in each rule, (2) both rules require that 
w directly connect to y, and (3) / not be filtered at y. Also notice that the (frame-tx-rx) 
rule requires that n not be a switch and f.dsthw = {Dn).ifaces[y].hwaddr. In contrast, 
the (frame-tx-switch-rx) rule states that this conclusion can also be derived if u is a 
switch, without any need to check the destination address. 

The network semantics given in Appendix A focuses exclusively on device protocol han¬ 
dling. Links are not represented in any way. As SOAC is about controlling access to 
services and not concerned with link bandwidth, information about links, other than their 
existence, is absent. Also absent in the semantics is the handling of any protocol that could 
influence logical organization (e.g. Routing Information Protocol (RIP), Open Shortest 
Path First (OSPF), or Dynamic Host Configuration Protocol (DHCP)). An algorithm for 
SOAC must have control over all such organization and allowing these kinds of protocols 
to run in the network would undermine it. 
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CHAPTER 4: 
Access Control Logic 


A network semantics like the one described in Chapter 3 and listed in Appendix A codifies 
commonly accepted network behavior in a system of inference rules. This system allows 
us to infer the presence application-layer connectivity given a network’s topology. Each 
conclusion reached in the semantics, which speaks in terms of rewrites allowed between 
variables, represents the presence of some communications path between an application 
running on a host and an application or service provided by a server. This is useful in 
automatically generating constraints on a network configuration for the purpose of allowing 
access to services on a network. However, the semantics does not address the issue of 
denying access to services on a network. 

We can develop a similar system that allows us to infer the absence of application-layer 
connectivity as well. This system, which we call the access control logic, allows us to 
reason about denying rewrites between variables such that each conclusion reached in the 
logic represents the absence of all possible communications paths between an application 
on a host and one on a server. Derivations in the semantics are existential in nature, where 
a derivation in the semantics corresponds with allowing a single path through the network 
between source and destination. In contrast, derivations in the logic are universal in nature, 
where a derivation in the logic corresponds with denying all possible paths between source 
and destination. 

In order to achieve this, the logic uses an inductive approach to deriving conclusions. We 
have a set of inference rules that resemble base cases, where one can infer a denied rewrite 
of a frame or packet between two variables based solely on the network’s topology or logi¬ 
cal organization. We also have a set of inference rules that resemble inductive steps. These 
inductive steps allow us to take applications of basic rules, traverse the network’s topology, 
and climb the network stack to infer negative rewrites of application-layer messages. We 
also have the ability to make assumptions about negative rewrites between interface vari¬ 
ables. These assumptions can be discharged in an inductive step by instrumenting access 
control at another place in the network where they would be subsumed. 
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This chapter provides a detailed deseription of the aeeess eontrol logie developed in this 
researeh. Seetion 4.1 deseribes the basie rules developed and therefore the instrumenta¬ 
tion available using this approaeh. Seetion 4.2 deseribes the eoneept of assumptions as it 
pertains to the aeeess eontrol logie, and how it provides flexibility in instrumenting the net¬ 
work. Seetion 4.3 deseribes induetive rules based on the network’s topology. Seetion 4.4 
deseribes induetive rules based on the network staek. Finally, Seetion 4.6 introduees the 
eoneepts of soundness and eompleteness and how they apply to the aeeess eontrol logie. 
The eomplete listing of inferenee rules in the aeeess eontrol logie is listed in Appendix B. 


4.1 Basic Rules 

The aeeess eontrol logie provides some inferenee rules that allow us to derive eonelusions 
about negative rewrites between variables using information eontained in the network map¬ 
ping. This information may be about the physieal topology, like whether an interfaee is 
direetly eonneeted to another interfaee, or about logieal organization, sueh as whether a 
filter eontains a eertain IP address. As with a derivation using the network semanties, a 
derivation using the aeeess eontrol logie produees a eonstraint set that must be satisfied and 
applied to the network to realize the desired eonelusion. The eonstraints generated in such 
a derivation are speeifieally generated with these basie rules. 

Rules in the aeeess eontrol logie resemble rules in the network semanties. Take the follow¬ 
ing rule, named (link-filter-dstip) as an example: 

switch ^ ipn).type 
host ^ {Dn).type 
p & P 

u G {Dm).if aces 

p.dstip G {Dn).ifaces[v].ifilter[dstip] 

D,A h {p,Ue) P {p,Vi) 

The rule’s eonelusion is stated below the horizontal line. All eonelusions in the logie take 
this form, where D is the network, A is the assumption set (to be introdueed in Seetion 4.2), 
p is the PDU value in question, Ue is the interfaee variable serving as the souree of the 
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rewrite, and vi is the destination variable. Requirements are expressed in the anteeedents 
of the rule above the horizontal line. 

This seetion provides details about the basie rules developed in this work. We begin with 
filter rules, whieh govern plaeement of paeket filters in the network. We then deseribe 
the (TERMINAL) rule, whieh provides some reasoning about terminal nodes. We then 
deseribe address mismateh rules, whieh provide reasoning about denying rewrites based 
on mismatehes between a paeket or frame destination address and an interfaee’s assigned 
address. Finally, we deseribe a rule governing forwarding table entries. 

4.1.1 Filter Rules 

The logie eontains several rules for denying rewrites between variables by installing ingress 
or egress filters. These rules eomprise the bulk of the basic rules defined in the logic. 
Basically, the filter rules state that a rewrite can be denied if some part of the datagram, 
specifically some piece of header information, is a member of a filter set on either the 
source interface or the destination interface. 

Filter rules are named intuitively so that a rule’s name identifies which piece of header 
information is filtered. For example, the (link-filter-dstip) rule captures requirements 
for denying a translation between variables by installing an ingress filter on the destination 
interface that filters based on a packet’s destination IP address. This rule is listed above. 

Notice the antecedents of the (link-filter-dstip) rule. They ensure that the destination 
device is neither a switch nor a host. This is because a switch can only filter based on 
frame header information, based on the provided network semantics, and because we do 
not trust a host’s configuration to enforce access control. The rule also ensures that the 
destination IP address of the packet p is contained in the destination interface’s ingress 
filter set. Figure 4.1 graphically depicts this rule. An IP packet gets blocked upon ingress 
at V. Notice that there is no specific relationship between u and v; the rule applies even with 
multiple intermediate nodes between the interfaces. 



Figure 4.1: Depiction of (link-filter-dstip) rule application 
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4.1.2 (terminal) Rule 


The (terminal) rule addresses the relationship between a terminal node and some other 
node in the network. It is the produet of the following observation. The network semanties 
says that a terminal node - usually an end host - will not forward a PDU baek through the 
interfaee through whieh it reeeived the PDU. Therefore, if a deviee m direetly eonneets 
via interfaee w to a terminal deviee n through interfaee v, any PDU sent from w to v will 
terminate at v. Therefore, the network’s physieal topology is enough to allow us to derive a 
eonelusion about a negative rewrite from u to some other interfaee x. Sinee a PDU d from 
u always terminates at v, we know that d will never reaeh x from u. Formally: 

{Dm).if ace s[u].direct = {v} 

{Dn).if aces = {v} 

V f X 

DjA h { d , Ue ) -fr { d ^ Xi ) 


Figure 4.2 depiets the applieation of this rule. Notiee that any traffie egressing from u 
terminates at v beeause there is no “U-turn” at v and beeause v is the only interfaee on n 
(as stated in the rule’s seeond anteeedent). Therefore, it is safe to say that traffie from u 
will never arrive at x, whieh is somewhere else in the network. Indeed, traffie from other 
interfaees on m may reaeh x, but that should be addressed elsewhere in the derivation. Our 
eoneem here is speeifieally traffie from u. 



Figure 4.2: Depiction of (terminal) rule application 
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4.1.3 Address Mismatch Rules 

The logic includes several rules for denying rewrites based on address mismatches. These 
rules basically codify the fact that a network interface on a device other than a switch or 
router will not accept a PDU that is not addressed to that interface, which is expressed in the 
network semantics. We do not consider “promiscuous” interfaces, but the semantics could 
be extended with a promiscuous host interface, in which case deriving a negative outcome 
for such an interface could not rely on address mismatch. These rules basically state that 
we can deny rewriting a PDU to an interface’s ingress variable if the destination address of 
the PDU does not match the interface’s address. We include a rule named (ip-address) 
for denying rewrites based on IP address mismatches and a rule named (HW-ADDRESS) for 
MAC address mismatches. The (ip-address) rule is listed below: 

p EP 

u G {Dm).if aces 

p.dstip f {Dn).ifaces[v\.ipaddr 

p.dstip 7 ^ 255.255.255.255 

router {Dn).type 

switch {Dn).type 

D,AE{p,Ue) 7^ {p,Vi) 

Several points should be explained here. First, we do not require mfnor any other specific 
relationship between the devices or interfaces. As with the filter rules, this rule applies 
even across multiple intermediate nodes. Second, this rule is unsound if n is a router, 
hence the antecedent that n is not a router. Third, the rule is sound for limited broadcasts 
(255.255.255.255) only. A more refined rule would be also sound for directed broadcasts 
and would require checking the destination interface’s subnet mask. Finally, soundness is 
mentioned here several times and is an important consideration throughout this system. We 
discuss this more in Section 4.6. 


4.1.4 (SUBNET) Rule 

The (subnet) rule allows denying rewrites between interfaces on the same device based 
on forwarding table entries. According to the network semantics, in order to route a packet 
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p from variable w, to on device n, p.dstip must match {Dn).ifaces[v\.dest. We leverage 
this requirement and say that we can deny rewriting p from Ui to Vg across m if p.dstip does 
not match {Dn).ifaces[v\.dest. This is formally captured below: 

M, V G {Dn).if aces 
p GP 

{Dn).if ace s[v].net mask = mask 
p.dstip & mask f {Dn).ifaces[v\.dest 
router G {Dn).type 
D,A h { p , Ui ) -fr ( p , Ve ) 

Figure 4.3 depicts this rule’s application. Notice that p is not blocked as if we installed a 
packet filter on the egress interface. Instead, p is simply not routed from m to v because 
p.dstip does not match the destination network of v. 


4.2 Assumptions 

The basic rules allow us to derive conclusions about negative rewrites based on information 
in the network mapping. For example, we can now deny a rewrite between two interface 
variables by placing a packet filter at either the source or destination. However, with these 
rules alone, we quickly see that our logic has a very limited ability to derive conclusions 
about negative rewrites across an entire network. We need mechanisms to allow us to reason 
about how applying these rules affects access control throughout the network. Furthermore, 
we need mechanisms that allow us to leverage topology in ensuring access control. 



%# 


u 

^ A 

n 

V 





Figure 4.3: Depiction of (subnet) rule application 
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One of these meehanisms is the idea of assumptions about negative rewrites. In many 
eases, we find that we are obligated to prove a eonelusion about a negative rewrite between 
two interface variables but that the basic rules alone do not provide any desirable options 
for doing so. In other words, we want to simply assume a negative rewrite so that we can 
continue the derivation in order to find another way to meet that obligation. Assumptions, 
when combined with the anti-forwarding rules that we introduce later, allow us the ability 
to reason about access control throughout the entire network. 

Assumptions take the same form as negative rewrite operations and are held in a set that is 
carried through a derivation. For example, to state an assumption about a negative rewrite 
of packet p from interface u on device m to interface v on device n, we simply state that 

{p,Ue) 7^ {p,Vi) eA. 

To govern the use of assumptions in the logic, we provide two inference rules, (link- 
ASSUMPTION) and (DEVICE-ASSUMPTION). The (LINK-ASSUMPTION) rule simply states 
that we can derive a conclusion about a negative rewrite from an egress variable to an 
ingress variable if that negative rewrite is in the assumption set. Formally: 

74 (djVi) GA 
Z),A h {d,Ue) 7-4 {d,Vi) 

Notice that we do not restrict assumptions based on the format of the PDU or on the rela¬ 
tionship between the two interface variables. This allows us freedom to make assumptions 
at any layer of the network stack and across any portion of the network. As we will see 
later, this freedom will translate into similar freedom in instrumenting the network. 

The (device-assumption) rule provides similar reasoning about negative rewrites from 
an ingress variable to an egress variable. This is used for assuming a negative rewrite 
within a device whereas the (link-ASSUMPTION) rule is used for assuming a negative 
rewrite across a link. 


4.3 Anti-Forwarding Rules 

With basic rules that govern how we actually instrument the network and with assumptions 
that allow us to carry proof obligations further along in the derivation, we have what we 
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need to introduee the anti-forwarding rules. This set of rules allows us to reason induetively 
about negative rewrites aeross the network. With these rules, we also introduee the eoneept 
of diseharging assumptions. By making an assumption, we ereate an obligation to reaeh 
that eonelusion elsewhere in the derivation. By diseharging an assumption, therefore, we 
instrument the network sueh that the obligation is rendered superfluous. Superfluous in this 
case means that the proof obligation is no longer necessary because another conclusion has 
been reached that subsumes that obligation. 

The key to allowing us to reason about network-wide access control in this logic is the 
understanding that we are free to choose where in the network to discharge the assumptions 
that we make. Say we make assumption about a negative rewrite between a router and an 
end host. We could discharge that assumption immediately by instrumenting the router. We 
could also carry that assumption to an upstream router and instrument the network there in 
such a way as to render the assumption superfluous. In this way, we have the freedom we 
need to ensure access control throughout the network. 

It is important to note that we must discharge all assumptions in a derivation before instru¬ 
menting the network. Remember that conclusions in the access control logic are based on 
both the network D and the assumption set A. If A is non-empty, there are proof obliga¬ 
tions that have not been met. Consider a service specification in SOAC that includes the 
negative rewrite {HTTP_RQ,Ue) {HTTP_RQ,Vi). Our goal, then, is to reach the con¬ 
clusion D,A h {HTTP_RQ,Ue) {HTTP_RQ,Vi), for some assumption set A. We begin 
by making some assumptions about access control enforced at places in the network where 
needed to advance the derivation but may be undesirable in practice to implement there. 
These assumptions may be discharged upstream by virtue of network topology or by intro¬ 
ducing access control at another place which subsumes them. In the latter case, they can 
be discharged, however, new assumptions arise due to introducing new access control else¬ 
where. In the end, A will contain assumptions that could not be discharged in the logic and 
therefore must be discharged outside the logic through instrumenting the network as they 
prescribe. This essentially produces a new network for which a derivation is now possible 
that ends with an empty A. 

In this section, we introduce three inference rules that govern this inductive reasoning based 
on the network’s physical topology. First, we describe the (fwd) rule, which allows us 
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to carry assumptions across a router, a switch, or any type network bridge in order to 
discharge them further upstream. Second, we describe the (link-fwd) rule, which allows 
us to discharge certain assumptions at a network bridge by instrumenting the network at the 
upstream link, specifically by applying a basic rule to that link. Finally, we introduce the 
(device-fwd) rule, which governs discharging certain assumptions at a network bridge 
by instrumenting the device itself. 

4.3.1 (FWD) Rule 

The (fwd) rule allows us to carry assumptions across across a device without instrument¬ 
ing that device. In doing so, we pass those assumptions further upstream so that we can 
meet those proof obligations elsewhere. Figure 4.4 shows a graphical depiction of this 
rule’s application. Notice that we have an upstream device m with interface u that is di¬ 
rectly connected to interface v of device n, which has three downstream interfaces wi, W 2 , 
and W 3 . Suppose we want to prove that Ug cannot rewrite some variable, say jc,, which may 
be reachable through wi, W 2 , or W 3 . For each downstream interface, we must first prove 
a negative rewrite between its egress variable and Xi (each depicted in the figure with a 
dark red “X”). If we can say that none of these egress variables is able reach xi, even by 
assumption, we can then say that the Ug is not able to rewrite Xi (depicted in the figure with 
a bright red “X”). This rule is formally listed here: 

V G {Dn).if aces 
{Dm).ifaces[u\.direct = {v} 

Vw G (Dn).if aces — {v}.D,A h {d,Wg) -fr {d,Xi) 

D,A h {d,Ug) 74 {d,Xi) 


Notice that the assumption set A does not change as a result of this rule. This means that 
any assumption made in reaching the conclusions involving the downstream interfaces will 
be carried along and must be discharged elsewhere in the derivation. 

4.3.2 (link-fwd) Rule 

The (link-fwd) rule allows us to discharge assumptions at a device by instrumenting a 
the network at the upstream link. By instrumenting the upstream link, we can consider all 
proof obligations downstream to be superfluous. Figure 4.5 depicts this rule’s application. 
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Figure 4.4: Depiction of (fwd) rule application 


The required topology is the same as in the (FWD) rule. As with the (fwd) rule, we also 
reaeh the required eonelusions about negative rewrites between the downstream interfaees 
and the destination interfaee. In aoeomplishing this, we build an assumption set A U 5. 
Then, we instrument the upstream link and prove a eorresponding negative rewrite. Any 
assumptions required to do so are eontained in the set A. Having done these things, we ean 
then diseharge all assumptions in S. Formally: 

V G {Dn).if aces 
{Dm).ifaces[u].direct = {v} 

Vw G (Dn).if aces — {v}. Z),A U 5 h {d,We) -ft {d,Xi) 

D,A h {d,Ue) -fr {d,Vi) 

D,A h {d,Ue) -ff {d,Xi) 
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Figure 4.5: Depiction of (link-fwd) rule application 


4.3.3 (device-fwd) Rule 

With the (device-fwd) rule, we diseharge assumptions not by instrumenting the upstream 
link but by instrumenting the deviee itself. We foeus here on preventing rewrites aeross the 
deviee, usually by either egress filtering or eonstraints on the deviee’s forwarding table. 
Again, the required topology is the same as the previous two rules. Also, the required 
assumptions involving downstream interfaees remain the same. Furthermore, we diseharge 
in a similar fashion. Figure 4.6 depiets the applieation of this rule, and it is stated below: 

V G {Dn).if aces 
{Dm).ifaces[u\.direct = {v} 

Vw G {D n) A faces — {v}.Z),A U5 h {d,We) -ft {d,Xi) 

Vw G {Dn)Afaces — {v}. Z),A h (J,v,-) -ft {d.Wg) 

D,A h {d,Ue) -ft {d,Xi) 
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Figure 4.6: Depiction of (device-fwd) rule application 

The difference between the (LINK-fwd) rule is in the fourth antecedent, which requires 
that we prove a negative rewrite from ingress variable v, to every downstream egress vari¬ 
able on n. 

4.4 Anti-Encapsulation Rules 

With the combination of the basic rules, assumptions, and anti-forwarding rules, we have 
a system that allows us to derive conclusions about negative rewrites across the entire net¬ 
work. By using assumptions, we can choose where to instrument the network, and we can 
use the anti-forwarding rules to block all possible paths from source to destination. 

However, the access control logic is still limited in that these rules only allow for reasoning 
about one particular layer of the network stack, usually a lower layer like the data-link or 
network layer. Remember that our goal is to develop a system that allows us to connect 
configuration at these lower levels to the uppermost layer where applications and services 
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reside. Therefore, we need a system that gives us freedom to traverse not only the network 
topology but also the network staek. 

To this end, the aeeess eontrol logie also provides inferenee rules that reason about negative 
rewrites at lower layers of the network staek and how those rewrites affeet negative rewrites 
at higher layers. For example, the (https_rq-encap) rule governs the relationship be¬ 
tween a negative rewrite of a HTTPS message and a negative rewrite of a TCP segment. 
The rule is listed below: 

seS 

s.data = a 
a = HTTPS_RQ 

D,A h (5, Mg) 74 ( 5 ,V,) 

h (a, Mg) 74 {a, Vi) 

Notiee that the rule establishes a relationship between the segment s and the HTTPS mes¬ 
sage a. This relationship, where s.data = a, eombined with the judgment that 5 at m eannot 
be rewritten as s at v, allows us to say that a at m also eannot be rewritten as a at v. 

The aeeess eontrol logie eontains anti-eneapsulation rules to eonneet the data-link layer, 
network layer, transport layer, and applieation-layer protoeols HTTPS and IRC. These 
applieation-layer protoeols are not speeial; others eould be introdueed. We present these as 
representative protoeols for the purpose of deseribing how applieations are handled. Like 
the example rule, eaeh of the anti-eneapsulation inferenee rules provide a negative rewrite 
as a eonelusion, a lower-layer negative rewrite as an anteeedent, and some eonstraints that 
eodify the relationship between the two negative rewrites. 


4.5 A Decision Procedure for the Logic 

A deeision proeedure for the logie has the property that if a derivation exists for a negative 
rewrite in the logie then the proeedure will say “yes”, otherwise it will say “no”. To make 
sueh a proeedure effieient, it is important to guide the eonstruetion of derivations in the 
logie as mueh as possible. The aeeess eontrol logie has been designed with this in mind. 
Speeifieally, it is “syntax-direeted” [33], [34]. 

The anti-forwarding rules are designed sueh that a derivation for a negative rewrite begins 
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at the destination and works its way back through the topology to the source. Consider 
the (fwd) rule as an example. Its third antecedent requires judgments of the form h 
{d,We) 74 {d,Xi) in order to reach the conclusion D,A h {d,Ue) {d,Xi), where w is on 
a device that is topologically closer to x than the device containing u. In other words, if 
we reach a conclusion of D,A h (d,We) {d,Xi), successive application of the (fwd) rule 
(or any anti-forwarding rule) yields D,A h {d,Ue) -/)■ {d,Xi), where u is directly upstream 
of w. In this rule and throughout the logic, we see that successive conclusions are derived 
in terms of the same destination but in terms of incrementally more distant sources. This 
makes the access control logic effectively syntax-directed. 

While syntax-directedness guides construction, there still remains much latitude for the 
decision procedure to choose from among many different derivations of the same negative- 
rewrite conclusion. While it is somewhat useful to know that if a negative rewrite deduction 
exists, a decision procedure can say so, we would like to know which instrumentations dif¬ 
ferent derivations prescribe for the network. Ideally, a procedure would compute the “best” 
derivation according to some heuristics governing network traffic, performance, forward¬ 
ing table size, etc. Such a procedure is beyond the scope of this thesis and is an area of 
future work. 


4.6 Soundness and Completeness 

There is a relationship between the access control logic and the semantics, and it is captured 
by the notions of soundness and completeness of the logic [34], [35]. In general, soundness 
and completeness describe how accurately a logical system represents reality. To say that a 
logical system is sound is to say that, if a statement can be shown in the system, it is indeed 
true in reality. Conversely, if any statement that holds in reality can be shown in the system, 
the system is said to be complete. For our purpose, reality is the network semantics, which 
codifies widespread, standards-based beliefs about how network devices behave. 

We can express soundness of the access control logic in the following way. For any 
negative rewrite of the form {d,Ue) {d,Vi) and for a given network D, if we derive 
D,A h {d,Ue) 74 {d,Vi) in the logic, instrumenting D according to A (by apply basic rules 
like filtering and subnetting) yields a network D' such that the corresponding positive 
rewrite (d^Ug) —)■ (d^Vi) cannot be derived in the semantics with respect to D'. Note that 
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if A is empty, D needs no instrumentation, and D' = D. In other words, if we derive a 
conclusion about a negative rewrite in the logic, the resulting instrumentation will render it 
impossible to derive a conclusion about the corresponding positive rewrite in the semantics. 
Ensuring the soundness of the access control logic is critical to ensuring effective access 
control in the network. 

Completeness says that, if there is a positive rewrite that is impossible to prove in the 
network semantics, then there exists a derivation in the logic to reach a conclusion about 
the corresponding negative rewrite. Completeness, for our purposes, is not as critical to 
the effectiveness of the logic as is soundness. If the logic is not complete, it is simply not 
leveraging all available capabilities to ensure access control. However, if the logic is not 
sound, it is not considering all possible paths, thereby falsely asserting access control. 

Here, it is important to reiterate that the logic’s soundness and completeness is measured 
against the network semantics, not against current networking capabilities. Consider, for 
example, an intrusion detection system (IDS) that operates in promiscuous mode, capturing 
all network traffic traversing a link. If this behavior were defined in the network semantics, 
then the address mismatch rules as written would be unsound because they falsely assert 
negative rewrites. However, we do not capture this behavior in the network semantics used 
in this thesis, so the behavior cannot be used to judge the logic as unsound. 
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CHAPTER 5: 
Scenarios 


USMC doctrine [36], [37] specifies that a USMC field artillery battalion typically consists 
of three firing batteries, each operating six 155-millimeter howitzers, and a headquarters 
battery that provides command, control, and support for the unit. To facilitate command and 
control, communications planners [38] typically establish a tactical data network through¬ 
out the battalion. 

Figure 5.1 depicts this typical network as deployed in operational environments. In this 
typical network, each battery operates on a switched LAN that is connected to an IP router 
and then to a radio transceiver. The battalion headquarters also operates on a switched LAN 
that may contain some servers. When the battalion is operating as part of a larger unit, the 
battalion headquarters will connect to that unit, and the battalion will use those services. 
However, when the battalion is operating independently, the headquarters will provide the 
necessary services. 

In some cases, an Ethernet mesh may replace radio systems as the network’s backbone. A 
battalion may use this approach in conducting digital communications exercises, where the 
unit establishes this network test its digital command and control abilities. A battalion may 
also take this approach if its firing batteries are located in close proximity. 

Figure 5.2 depicts the physical topology of a typical field artillery battalion’s network with 
an Ethernet mesh backbone. This network lends itself well to the SOAC framework for 
two reasons. First, security requirements in this network are often fine-grained. By fine¬ 
grained, we mean that two hosts on a LAN may require access to different services; one 
host may be granted access to a server when another host on the same LAN may be denied 
access to the same server. Second, security requirements are often expressed in terms of 
services. 

Take a battalion’s mission planning process as an example. A battalion commander often 
expresses communications requirements in the following way. Some service will serve as 
the primary means of command and control and these units will use it, some other service 
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Figure 5.1: Common Marine Corps field artillery battalion data network 


will serve as the secondary means and these units will use it, and so on. The battalion 
communications officer will then build a plan to support those requirements using the data 
network. With SOAC, those requirements can be used directly as input for developing the 
network configuration. 

This chapter describes three scenarios where we use the SOAC framework to achieve an 
access control strategy by systematically generating constraints on the network. In the first 
scenario, we restrict access to the battalion’s SharePoint server to only hosts in the battalion 
headquarters, showing how we take a simple service specification and apply our framework. 
In the second scenario, we maintain the SharePoint server access restriction while granting 
a host in Battery B access to the battalion’s IRC server, introducing conflicting derivations 
that we resolve. Finally, we adjust the topology and introduce a service specification with 
an unresolvable conflict to show how our approach handles such a case. 


5.1 First Scenario: Basic Use 

Let D represent the network depicted in Figure 5.2. Consider a scenario where we must 
limit SharePoint access to hosts in the battalion headquarters. More specifically, we must 
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Figure 5.2: Physical network topology for common Marine Corps field artillery battalion data 
network 


ensure that all hosts loeated in the battalion headquarters - namely, bn_co, bn_xo, bn_sl, 
bn_s3, and bn_s4 - ean aeeess the SharePoint server, and we must deny aeeess to all other 
hosts in the network. 

This requirement translates to several eonelusions to be derived using either the network 
semanties or the aeeess eontrol logie. These eonelusions are listed in Figure 5.3. We 
look at two of these desired outeomes in detail. First, we eonsider the desired eonelu- 
sion D h {HTTPS_RQ,bn_co_ethe) —?■ {HTTPS_RQ,bn_https_ethi), whieh we use the 
network semanties to derive. Seeond, we eonsider D,0 h {HTTPS_RQ,a_co_ethe) -/)■ 
[HTTPS_RQ,bn_https_ethi), whieh we use the aeeess eontrol logie to derive. 
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D\- {HTTPS_RQ,bn_co_ethc) {HTTPS_RQ,bn_https_ethi) 

Dh- {HTTPS_RQ,bn_xo_ethe) {HTTPS_RQ,bn_https_ethi) 

D\- {HTTPS_RQ,bn_s2_eth,) {HTTPS_RQ,bn_https_ethi) 

Dh {HTTPS_RQ,bn_s3_eth,) {HTTPS_RQ,bn_https_ethi) 

Dh {HTTPS_RQ,bn_s4_eth,) {HTTPS_RQ,bn_https_ethi) 

D,(dh (HTTPS_RQ,a_co_eth,) > (HTTPS_RQ,bn_https_ethi) 

D,l/)h (HTTPS_RQ,a_xo_ethe) (HTTPS_RQ,bn_https_ethi) 

D,%h {HTTPS_RQ,a_bg_ethe) > {HTTPS_RQ,bn_https_ethi) 

D,%\- {HTTPS_RQ,b_co_ethe) (HTTPS_RQ,bn_https_ethi) 

D,%\- (HTTPS_RQ,b_xo_ethe) (HTTPS_RQ,bn_https_ethi) 

0,%^ {HTTPS_RQ,b_bg_etK) {HTTPS_RQ,bn_https_ethi) 

D,%\- (HTTPS_RQ,c_co_ethe) (HTTPS_RQ,bn_https_ethi) 

D,%\- {HTTPS_RQ,c_xo_ethe) 74 (HTTPS_RQ,bn_https_ethi) 

D,%\- (HTTPS_RQ,c_bg_ethe) {HTTPS_RQ,bn_https_ethi) 

Figure 5.3: Service specification excerpt, first scenario 

5.1.1 Positive Derivation 

Consider the first desired conclusion, where an HTTPS request leaving from the battalion 
commander’s host should translate to an HTTPS request arriving at the battalion’s Share- 
Point server. The required derivation involves searching the network semantics for a path 
from the source incrementally through the network to the destination and then using the 
transitive property of the rewrite operation to reach the intended conclusion. 

The derivation begins at the source with the (https_RQ-encap) rule: 


51 = (71,72,73,«) 

a = HTTPSJtQ 

71 = tcp 

72 G {D bn_co) .portrange 

D h {a,bn_co_ethg) —)■ {s\^bn_co_ethg) 


In applying this rule and reaching this conclusion, we generate some constraints on D that 
are necessary to allow the rewrite to occur. For example, host G {Dbn_co).type must be 
satisfied to reach this conclusion. As a result, fresh variables 5 i, a, 71 , 72 , and 73 are 
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generated. The derivation eontinues with the (packet-encap) rule: 


Pi = (74,75,^0 

76 = {Dbn_co).ifaces[bn_co_eth].netmask 
75 & 76 = {Dbn_co).ifaces[bn_co_eth].dest 
74 = {Dn).ifaces[w\.ipaddr 

74 ^ {Dbn_co).ifaces[bn_co_eth].efilter[srcip] 

75 ^ {Dbn_co).ifaces[bn_co_eth].efilter[dstip] 

D h {s\,bn_co_ethe) —)■ {pi,bn_co_ethe) 

We generate more eonstraints on D as we reaeh this eonelusion. We also generate more 
fresh variables (i.e., p\, 74 , 75 , and 76 ). At this point, we also see eonstraints on the log- 
ieal organization of D. For example, we eonstrain {Dbn_co).ifaces[bn_co_eth].netmask, 
whieh eorresponds with the subnet mask of the interfaee bn_co_eth. 

The derivation eontinues in this way, where we seareh for a path from the souree inere- 
mentally through the network to the destination. For the sake of brevity, several steps are 
omitted here. As the derivation progresses, we generate more eonstraints. At the destina¬ 
tion, the (https_rq-decap) rule applies: 

Yz = 443 

D h {si,bn_https_ethi) —)■ {a,bn_https_ethi) 

Upon reaehing the destination, we see the transitive property of the rewrite operation help 
reaeh the final eonelusion. The (trans) is used for this purpose: 

D h {p\,bn_https_ethi) —)■ {si,bn_https_ethi) 

D h [si^bnjittps_ethi) —)■ (a,bn_https_ethi) 

D h {p\,bn_https_ethi) —)■ {a,bn_https_ethi) 

The (TRANS) rule essentially eonneets the individual eonelusions together. Both premises 
used here are eonelusions reaehed earlier. Also, notiee that no new eonstraints are generated 
after applying the (trans) rule. This is expeeted sinee we are simply using the transitive 
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property of the rewrite operation to complete the derivation. We continue with successive 
applications of the (TRANS) rule, working backward from the destination to the source, 
until we are able to derive our desired conclusion: 

D h {a,bn_co_ethe) —)■ {si,bn_co_ethe) 

D h {si,bn_co_ethe) —)■ {a,bn_https_ethi) 

D h {a,bn_co_ethe) —)■ {a,bn_https_ethi) 

With this derivation, we effectively prove, based on the network semantics, that the bat¬ 
talion commander’s host can send an HTTPS request to the SharePoint server. Several 
constraints on D are generated as a result. The complete set of constraints from the deriva¬ 
tion is listed in Figure 5.4. By satisfying these constraints, we can produce a constrained 
D that corresponds with a logical organization that can be applied to the network’s devices. 
This logical organization can realize our service-level goals. 

5.1.2 Negative Derivation 

Now consider the second desired conclusion, where an HTTPS request leaving from the 
Battery A commander’s host must not translate to an HTTPS request at the battalion’s 
SharePoint server. Note that D has already been constrained as a result of the previous 
derivation. 

We begin at the destination and work our way back to the source. We also choose to focus 
on the bn_router device for any instrumentation. Therefore, we use the (ASSUMPTION) 
rule to eliminate any instrumentation needs downstream of bn_router. 

Pi = ( 79 , 710 ,^ 2 ) 

Ai = {{p 2 ,bn_router_eth 0 e) {p 2 ,bn_https_ethi)} 

D,Ai UA 2 UA 3 UA 4 UA 5 h {p2,bn_router_eth0e) {p 2 ,bn_https_ethi) 

Ai = {{p 2 ,bn_router_eth 2 e) -/)■ {p 2 ,bn_https_ethi)} 

D,Ai UA 2 UA 3 UA 4 UA 5 h {p2,bn_router_eth2g) {p 2 ,bn_https_ethi) 

A 3 = {{p2,bn_router_eth3e) {p 2 ,bn_https_ethi)} 

D,Ai UA 2 UA 3 UA 4 UA 5 h {p2,bn_router_eth3e) {p 2 ,bn_https_ethi) 
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a = HTTPS_RQ 

7i ^ tcp 

Ji G {Dbn_co). port range 

Pi -(74,75,^1) 

7g = (Dbn_co).ifaces[bn_co_eth].netmask 
75 & 7g = (Dbn_co).ifaces[bn_co_eth\.dest 
74 = (Dbn_co).ifaces[bn_co_eth].ipaddr 

74 ^ (Dbn_co).ifaces[bn_co_eth].efilter[srcip] 

75 ^ {pbn_co)Afaces[bn_co_eth\.efilter[dstip] 
f\ = {ri, 7 i,pi) 

Yi — (Dbn_co).ifaces[bn_co_eth].hwaddr 
f] 4 - (Dbn_co).ifaces[bn_co_eth].efilter[srchw\ 

Y, ^ (Dbn_co).ifaces[bn_co_eth].efilter\dsthw] 

Y] ^ (Z)Pn_5'wiYc/2).i/<3ce5[Pn_.s'w//c‘/2_^//27].i’////^r[5rc‘/iw] 

^ (DPrt_.s'wiYc/2).i/flc^5[p7i_5'w//c/2_^?/25].^/i7?^r[5rc/2vv’] 

7g = (Dbn_https).ifaces[bn_https_eth].hwaddr 
Yi ^ (Dbn_https).ifaces[bn_https_eth].ifilter[srchw\ 

Y, ^ {Dbn_https).ifaces[bn_https_eth].ifilter[dsthw] 

74 ^ (Dbn_https).ifaces[bn_https_eth].ifilter[srcip] 

75 ^ (Dbn_https).ifaces[bn_https_eth].ifilter[dstip] 

74 = (Dbn_https).ifaces[bn_https_eth].ipaddr 

{y\-,yi) t (Dbn_https).ifaces[bn_https_eth].ifilter[srcport\ 
{7 i»73 ) ^ (Dbn_https).ifaces[bn_https_eth].ifilter[dstport] 
Yi ^ 443 


Figure 5.4: Result of positive derivation, first scenario 

Notice that we assume negative conclusions about negative rewrites from every interface on 
bn_router to bn_https_eth except from bn_router_eth\, which is directly connected to the 
upstream a_router_eth\ interface. This prepares us to apply the inductive (device-FWD) 
rule to bn_router. The (device-FWD) rule requires us to reach conclusions about negative 
rewrites from every egress variable on a device, except the variable associated with the up¬ 
stream interface. It then requires us to reach conclusions about negative rewrites between 
the interfaces on the bn_router device. We use rules like (device-fieter-dstip), which 
introduces a packet filter matching a packet’s destination IP address, and (SUBNET), which 
constrains the device’s forwarding table. Once we reach a conclusion about a negative 
rewrite between two of these interfaces, we then apply the rule to discharge the appropri- 
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ate assumptions as superfluous. This part of the derivation begins with application of the 
(subnet) rule in order to discharge A2: 

7ii = {Dbn_router).ifaces[bn_router_eth 2 ].netmask 
7io & 7ii 7^ {pbn_wuter).ifaces[bn_router_eth 2 ].dest 
Z),A4UA5 h {p2,bn_router_ethli) -/)■ {p2,bn_router_eth2e) 

Notice that constraints on the device’s forwarding table appear here. These constraints, 
when satisfied, will be used to instrument D. We use the (subnet) rule again to help 
discharge A3. This leaves Ai, which is treated with the (device-filter-dstip) rule: 

7io € {Dbn_router).ifaces[bn_router_ethO\.efilter[dstip\ 

Z),A4UA5 h {p2,bn_router_ethli) -/)■ {p2,bn_router_eth0e) 

We have now reached all conclusions required by the (device-fwd) rule. This rule is 
applied to discharge assumptions Ai, A2, and A3, allowing us to continue the derivation 
further upstream. We apply the rule here: 

Z),Ai UA2UA3 UA4UA5 h {p 2 ,bn_router_eth 0 e) {p2,bn_https_ethi) 

D,Ai UA2UA3 UA4UA5 h {p 2 ,bn_router_eth 2 e) {p2,bn_https_ethi) 

D,Ai UA2UA3 UA4UA5 h {p 2 ,bn_router_eth 3 e) {p2,bn_https_ethi) 
Z),A4UA5 h {p2,bn_router_ethli) -/)■ {p2,bn_router_eth0e) 

Z),A4UA5 h {p2,bn_router_ethli) -/)■ {p2,bn_router_eth2e) 

D^A^UA^ h {p2,bn_router_ethli) -/)■ {p 2 ,bn_router_eth 3 e) 

Z),A4UA5 h {p2,a_router_ethle) {p2,bn_https_ethi) 

At this point, we find that the packet p2 cannot be rewritten from interface a_router_eth\ 
to bn_https_eth. In effect, we block every path through the network for this packet to travel 
from a_router_eth\ to bn_https_eth. 

In this scenario, however, there are other paths from the source to the destination. These 
paths must be blocked as well, so we continue the derivation. We treat a_router with a 
similar strategy as before. First, we make some assumptions as we did previously. Second, 
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we apply rules that introduce an instrumentation on the target device. Third, we apply an 
anti-forwarding rule to discharge the appropriate assumptions. This strategy allows us to 
reach the conclusion D,0 h {p2,a_switch_eth0e) 7^ {p2:bn_https_ethi). 

At this point, the (terminal) rule becomes useful. We use the rule to reach negative 
conclusions about devices on the same LAN as the source by showing that each port on 
a_switch terminates with a device that is not the destination. We apply the rule to all 
interfaces on the switch besides the interface connected to a_co to prepare for using the 
(fwd) rule. Recall that we must reach conclusions about negative rewrites from all egress 
variables on the target device to the destination. Having accomplished this with the (ter¬ 
minal) rule, the derivation continues by applying the (fwd) rule: 

Z),0 h {p2,a_switch_eth0e) {p2,bn_https_ethi) 

Z),0 h {p2, a_switch_ethle) {p2,bn_https_ethi) 

Z ),0 h {p 2 ,a_switch_eth 3 e) -/)■ {p2,bn_https_ethi) 

Z ),0 h {p2, a_switch_ethAg) -/)■ {p2,bn_https_ethi) 

Z),0 h {p2, a_switch_eth 5 e) {p2,bn_https_ethi) 

Z),0 h {p2,a_co_ethe) {p2,bn_https_ethi) 

Therefore, we can successfully derive the conclusion that, given only the mapping D, the 
packet p2 at a_co_eth cannot be rewritten as p2 at bn_https_eth. However, we need to 
reach a conclusion in terms of the application-layer HTTPS_RQ. Therefore, we continue 
the derivation using the (SEG-encap) and (https_rq-encap) rules to arrive at the fi¬ 
nal conclusion of Z ),0 h {a,a_co_ethe) -/)■ {a,bn_https_ethi). Now, similar to the positive 
case, we show that, given only the mapping D, the message HTTP_RQ at a_co_eth cannot 
be rewritten as HTTP_RQ at bn_https_eth. In plain English, we show that the battery 
commander’s host cannot send an HTTPS request to the SharePoint server. Several con¬ 
straints are generated as a result and are listed in Figure 5 . 5 . By combining this set with 
the one generated in the positive derivation, we will have a constraint set whose satisfying 
substitution will allow us to configure the network to realize both the positive and negative 
service-level goals. 
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P 2 = (79.710,^2) 

A\ — {(p 2 ,bn_router_eth 0 e) {p2,bn_https_ethi)} 

A2 — {(p2-,bn_router_eth2e) {p2,bn_https_ethi)} 

A3 = {{p 2 .,bn_router_eth 3 e) {p2,bn_https_ethi)} 

Yii — (Dbn_router).ifaces[bn_router_eth 2 ].netmask 
7 io & 7 ii ^ (Dbn_router).ifaces[bn_router_eth 2 ].dest 
Y[2 — (D bn_router) .ifaces[bn_router_eth 3 ].netmask 
7io & 7i2 ^ (Dbn_router).ifaces[bn_router_eth 3 \.dest 
7 io € (Dbn_router).ifaces[bn_router_ethO].efilter[dstip] 
A4 = {{p2,a_router_eth2e) -ff {p2,bn_https_ethi)} 

A5 = {(p 2 .,a_router_eth 3 e) 7^ (p2,bn_https_ethi)} 

Y12 — (Da_router).ifaces[a_router_eth 2 ].netmask 
7 io & 7 i3 ^ (Da_router).ifaces[a_router_eth 2 ].dest 

714 = (Da_router).ifaces[a_router_eth 2 ].netmask 
7 io & 7 i4 (Da_router).ifaces[a_router_eth 3 ].dest 

= [Dbn_https).ifaces[bn_https_eth].ipaddr 
^2 ^ ( 715 ) 716 i 717 )‘ 3 ) 

715 - 

717 - 443 
- HTTPS_RQ 


Figure 5 . 5 : Result of negative derivation, first scenario 


5.2 Second Scenario: Resolvable Conflicts 

Consider another scenario where, though firing battery commanders are denied access to 
the battalion’s SharePoint server, they are allowed access to the IRC server for tactical chat 
and messaging. Though we must derive several conclusions to meet this requirement, we 
look at only two in order to illustrate the approach. First, we consider the desired positive 
conclusion D h {IRC_MSG,b_co_ethe) —)■ {IRC_PRIVMSG,bn_irc_ethi), which we de¬ 
rived with the network semantics. Second, we consider D, 0 h {HTTPS_RQ^ b_co_ethe) -A 
{HTTPS_RQ,bn_https_ethi), which derive with the access control logic. 


5.2.1 Positive Derivation 

Consider the first desired conclusion; we seek to show that an IRC private message at the 
Battery B commander’s host would translate to an IRC private message at the battalion’s 
chat server. Our approach here is similar to our approach in the previous scenario. We 
begin at the source and work our way to the destination. 
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The derivation specifically begins with the (irc_privmsg-encap) rule: 


ai =IRC_PRIVMSG 
51 = (71,72,73,«i) 

7 1 = fcp 

72 G {D b_co) .portrange 

D h {ai,b_co_ethe) —)■ {si,b_co_ethg) 

The derivation continues here similar to the positive derivation in the previous example. In 
this scenario, however, our path takes us to the device b_router. To show the routing of the 
IP packet across this router, we apply the (router) rule: 

79 = {Db_router).ifaces\b_router_ethl].netmask 
75 ^ 255 . 255 . 255.255 

75 7^ -179 I {Db_router).ifaces[b_router_eth 2 ].dest 
75 & 79 = {Db_router).ifaces[b_router_eth 2 ].dest 

74 ^ {Db_router).ifaces[b_router_eth 2 ].efUter[srcip\ 

75 ^ {Db_router).ifaces[b_router_eth 2 ].efilter[dstip\ 

D h {pi,b_router_ethOi) —)■ {pi,b_router_eth 2 e) 

Notice here that several constraints are placed on subnet mask, destination IP address, and 
forwarding table. These constraints, when satisfied, ensure that the router forwards the 
packet based on matching network prefix to the appropriate interface. 

With respect to the network topology, we find ourselves now inside the network’s Ethernet 
backbone. Our derivation, however, continues in the familiar way, with encapsulations 
followed by transmissions followed by decapsulations. We apply the (router) rule again 
once we reach the battalion’s router, and then we continue through the battalion’s LAN. 

Having reached our destination, the device bn_irc, we begin to apply rules to decapsu- 
late the frame. We begin with the (frame-decap) rule and conclude by applying the 
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(IRC_PRIVMSG-DECAP) rule: 


73 = 6667 

D h {si,bn_irc_ethi) —)■ {ai,bn_irc_ethi) 

Similar to the previous scenario, the derivation continues backward toward the source 
with the (TRANS) rule successively applied until we reach the ultimate conclusion of 
D h {a\,b_co_ethi) —)■ {ai,bn_irc_ethi). Again, we use this derivation to prove that an 
IRC private message can be sent from the Battery B commander’s host to the battalion’s 
chat server. 

In doing so, we generate more constraints to apply to the mapping D. Our constraint set 
here is much larger than the set generated in the previous scenario, due to the increased 
length of the path through the network. Figure 5.6 shows a portion of the constraint set. A 
satisfying substitution can then be applied to the network’s devices to realize our service- 
level goals here. 

5.2.2 Negative Derivation 

Now consider the second desired conclusion, where the battery commander should not have 
access to the battalion’s SharePoint server. We take an approach similar to the approach in 
the previous scenario. We begin at the destination and work our way back to the source. 

In this scenario, though, we decide to focus on the device b_router for instrumenting the 
network. We begin by making assumptions about connectivity between bn_https_eth and 
the interfaces of b_router. We use the (ASSUMPTION) rule to declare three assumptions 
like the following: 

P 2 = (715,716A2) 

Ai = {p2,b_router_eth2e) -/> {p2,bn_https_ethi) 

D,Ai UA2UA3 h {p2,b_router_eth2e) -/)■ {p2,bn_https_ethi) 

We decide to leverage the (link-fwd) rule to discharge all three assumptions at once. 
In order to do that, we introduce constraints on the link directly upstream from the 
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a I ^IRC_PRIVMSG 

s\ - 
7i ^ tcp 

— (D b_router) .ifaces[b_router_ethO].hwaddr 
y] (Db_router).ifaces[b_router_ethO].ifilter[srchw] 
y^ f. (Db_router).ifaces[b_router_ethO].ifilter[dsthw\ 

(71^72) ^ {Dbn_irc).ifaces[bn_irc_eth].ifilter[srcport] 

(7i?72) ^ (Dbn_irc).ifaces[bn_irc_eth].ifilter[dstport] 
y^ - 6667 

Figure 5 . 6 : Excerpt of fresh variables generated during positive derivation, second scenario 


router. Specifically, we decide to introduce MAC address filtering on the router’s inter¬ 
face b_router_ethO, which is connected to the Battery B LAN. We therefore apply the 
(LINK-FILTER-DSTHW) rule: 

h = (717,718,.P2) 

7i8 € {Db_wuter).ifaces[b_router_ethO\.ifilter[dsthw] 

D,0 h {f4,b_switch_eth0e) -/> {f4,b_router_eth0i) 

We then apply the (pkt-encap) rule, which is what we need in order to apply the (link- 
ewd) rule to discharge the assumptions: 

D,Ai UA2UA3 h {p2,b_router_ethle) 74 {p2,bn_https_ethi) 

D,Ai UA2UA3 h {p2,b_router_eth2e) -/)■ {p2,bn_https_ethi) 

D,Ai UA2UA3 h {p 2 ,b_router_eth 3 e) {p2,bn_https_ethi) 

D ,0 h {p2,b_switch_eth0e) -/> {p2, b_router_ethOi) 

D ,0 h {p2,b_switch_eth0e) -/> {p2, bn_https_ethi) 

Inside the Battery B LAN, we use the same strategy as the one in the previous scenario. 
The (terminal) rule is used to show negative conclusions about the other devices on 
the LAN. Doing this allows us to continue the derivation and reach a conclusion about a 
negative rewrite between the source and destination. By using the (fwd) rule, we reach 
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Pi ^ (7l5,ri6,‘?2) 

A\ — (p 2 ,b_router_eth 2 e) {p2,bn_https_ethi) 

A2 — (p2,b_router_ethle) (p2^bn_https_ethi) 

A3 = (p 2 ,b_router_eth 3 e) {p2,bn_https_ethi) 

/a ^ ( 717 , 718 ,/> 2 ) 

7 1 8 € {Db_router).ifaces[b_router_ethO].ifilter[dsthw] 
yjg = (Db_router).ifaces[b_router_ethO].hwaddr 

= (Dbn_https).ifaces[bn_https_eth\.ipaddr 
^2 ^ ( 719 ) 720 ? 721 )‘ 32 ) 

719 ^ tcp 
Yix -443 

<32 - HTTPS_RQ 


Figure 5 . 7 : First attempt, negative derivation, second scenario 


the conclusion D ,0 h {p2,b_co_ethe) -A {p2,bn_https_ethi). We continue by using the 
(SEG-ENCAP) and (https_rq-encap) rules to arrive at the final conclusion of D ,0 h 
{a2,b_co_ethe) -A {a2,bn_https_ethi). 

We find that this derivation generates constraints that contradict those generated in the 
positive derivation. By using unification, we find that the negative derivation yields the 
following constraint: 

{D b_router).ifaces[b_router_ethO\ .hwaddr 

G {Db_router).ifaces[b_router_ethO\.ifilter[dsthw\ 

This contradicts a constraint generated in the positive derivation: 

[D b_router).ifaces[b_router_ethO\ .hwaddr 

^ {Db_router).ifaces[b_router_ethO\.ifilter[dsthw] 

It is clear, therefore, that the union of these two sets is unsatisfiable. 

We know by intuition that this conflict can be resolved by trying a different derivation 
to reach the second conclusion. We can focus our efforts on a different device besides 
b_router by adjusting our assumptions, or we can simply adjust our instrumentation. We 
choose to adjust the instrumentation by filtering based on IP address rather than MAC 
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address. 


We restart our derivation, following the same strategy as before. We use the (link-filter- 
DSTIP) on b_wuter before applying (link-fwd): 

7 i6 € {Db_wuter).ifaces[b_wuter_ethO\.ifilter[dstip\ 

Z),0 h {p2,b_switch_eth0e) -/> {p2,b_router_eth0i) 

The derivation eontinues as before, eventually reaehing the final eonelusion. The result 
is listed in Figure 5 . 8 . By inspeetion, we find that our eonfliet is resolved. The union of 
these two sets will result in a satisfiable eonstraint set, one whose satisfying substitution 
will allow us to eonfigure the network to realize both the positive and negative serviee-level 
goals. 


5.3 Third Scenario: Unresolvable Conflicts 

In the previous seenarios, we sueeessfully applied the SOAC approaeh to generate eon- 
straints on a network eonfiguration for realizing serviee-level goals. In the first seenario, 
we did this without any eonfliet between our positive derivation and our negative deriva¬ 
tion. In the seeond seenario, we found that, after eompleting the positive derivation, our 
first attempt at the negative derivation ereated a eonfliet and an unsatisfiable eonstraint set. 
We addressed this eonfliet in our seeond attempt at the negative derivation. We adjusted 
our instrumentation of the network, and we resolved the eonfliet. 

We now introduee a seenario that presents an unresolvable eonfliet between positive and 
negative derivations. We adjust the network topology to eorrespond with the network in 
Figure 5 . 9 . One physieal deviee, bn_server, is providing both the SharePoint and IRC 
serviees for the network, whieh eonsists of a single router and two hosts, c_co and c_xo, 
eonneeted via a switch. In order to access each service, hosts will send messages to the 
same interface - and therefore the same IP address - but to different ports. In this scenario, 
we must grant SharePoint access to the Battery C commander’s host and IRC access to the 
Battery C executive officer’s host. We must also deny SharePoint access to the executive 
officer’s host and deny IRC access to the commander’s host. 
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Ai — (p2ib_router_eth2e) -fr {p2,bn_https_ethi) 

A2 — (p2ib_router_eth\e) {p2,bn_https_ethi) 

A3 — (p2-,b_router_eth?>e) {p2-,bn_https_ethi) 

P2 = (ri5,ri6,'S2) 

7i6 G {Db_router).ifaces[b_router_ethO].ifilter[dstip] 

716 = {D bn_https) .ifaces[bn_htt ps_eth].ipaddr 
S2 = (717,718,719i'22) 

7 17 = tcp 
7i9 = 443 

a2 = HTTPS_RQ 


Figure 5 . 8 : Second attempt, negative derivation, second scenario 



C CO 


Figure 5 . 9 : Physical topology of example network with single server 


5.3.1 Positive Derivations 

As with the previous seenarios, we begin by pursuing the positive eonelusions. Here, 
we first derive D h {HTTPS_RQ,c_co_ethe) —)■ {HTTPS_RQ,bn_server_ethi). In plain 
English, we seek to show that the Battery C eommander’s host ean aeeess the bat¬ 
talion’s SharePoint service. Second, we derive D h {IRC_PRIVMSG,c_xo_ethe) —t 
{IRC_PRIVMSG, bn_server_ethi). In plain English, we then seek to show that the Bat¬ 
tery C executive officer’s host can access the battalion’s IRC service. 

Our strategy here is to search the network semantics for a rule to help us incrementally 
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derive the final conelusion. We begin by applying the (HTTPS_RQ-encap) rule: 

ai = HTTPS_RQ 
si = {rhr2,r3,ai) 

n = fcp 

72 G {D c_co).port range 
D h {ai,c_co_ethe) —)■ {s\^c_co_ethg) 

The derivation eontinues in this way, similar to the previous seenarios, until we reach the 
destination and apply the (https_rq-DECAP) rule: 

73 = 443 _ 

D h {si,bn_server_ethi) — {a\^bn_server_ethi) 

Using the (TRANS) rule, we finally reach the desired conclusion: 

D h {ai,c_co_ethi) —)■ {si^c_co_ethi) 

D h {si,c_co_ethi) —)■ {ai,bn_server_ethi) 

D h {ai,c_co_ethi) —)■ {ai,bn_server_ethi) 

Having completed this derivation, we can prove the first part of our desired positive out¬ 
comes. We continue to derive the second desired conclusion, that the Battery C executive 
officer’s host can access the battalion’s IRC service. We complete this derivation in a man¬ 
ner very similar to the first derivation. Figure 5.10 shows an excerpt of the results of the 
derivations. 

5.3.2 Negative Derivations 

Having completed the positive derivations, we now pursue the negative derivations. How¬ 
ever, we cannot derive the first desired conclusion without creating a conflict with a con¬ 
straint generated in one of the positive derivations. We conduct an exhaustive search for 
a derivation in the access control logic and find that one does not exist. Described here is 
one attempt at the link layer of the network stack, one attempt at the network layer, and one 
attempt at the transport layer. 


57 



ai = HTTPS_RQ 
*1 = (71,72,73,^1) 

7i = tcp 

{ 71 , 72 ) ^ {Dbn_server).ifaces[bn_server_eth].ifilter[srcport] 
{ 71 , 72 ) ^ {Dbn_server).ifaces[bn_server_eth].ifilter[dstport\ 
Yi = 443 

02 = IRC_PRIVMSG 
^2 = ( 715 . 716 i 717 :' 32 ) 

715 = tcp 


(7i5j 7i6) ^ {Dbn_server).ifaces[bn_server_eth].ifilter[srcport\ 

( 7 i 5 j 7i6) i {Dbn_server).ifaces[bn_server_eth].ifilter[dstport\ 

7 i 7 = 6667 

Figure 5 . 10 : Excerpt of fresh variables generated during positive derivations, third scenario 


Link Layer 

In this attempt, we decide to focus on MAC filtering at the device bn_router. We begin 
by making an assumption about connectivity between bn_router and bn_server. We then 
apply the (link-filter-dsthw) and (pkt-encap) rules for instrumentation: 

721 £ {Dbn_router).ifaces[bn_router_ethO].ifilter[srchw\ 

Z ),0 h {f4^c_switch_eth0e) -/> {f4,bn_router_eth0i) 

Z ),0 h {f4,c_switch_eth0e) -/)■ {f4,bn_router_ethOi) 

D ,0 h {p2t c_switch_ethOg) -/)■ {p2,bn_router_eth0i) 

The assumption is discharged using the (link-fwd) rule: 

D,Ai h {p2,bn_router_ethle) -/> {p2,bn_server_ethi) 

D, 0 l- {p2TC_switch_eth0e) -/> {p2,bn_router_eth0i) 

D, 0 l- {p2TC_switch_eth0e) -/> {p2,bn_server_ethi) 

From here, we use the (terminae) rule to reach back to the source, and then we apply the 
encapsulation rules (seg-encap) and (irc_privmsg-encap) to complete the derivation. 
The result is shown in Figure 5 . 11 . 
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Aj = (p2^bn_router_eth\e) (p2^bn_server_ethi) 
y2i G (Dbn_router).ifaces[bn_router_ethO].ifilter[srchw] 


Figure 5.11: First attempt, negative derivation, third scenario 

As expected, this derivation generates a constraint that contradicts one generated in the 
positive derivation. By using unification, we find that our negative derivation yields the 
following: 


{D c_xo).ifaces [c_xo_eth] .hwaddr 

G {Dbn_wuter).ifaces[bn_router_ethO]dfilter[srchw\ 

This contradicts the following constraint generated in the positive derivations: 

{D c_xo).ifaces [c_xo_eth] .hwaddr 

^ ipbn_router).ifaces[bn_router_ethO].ifilter[srchw] 

A similar conflict arises after every attempt to introduce MAC filtering. We must move on 
to instrumentation at the network layer. 


Network Layer 

In this attempt, we focus on IP packet filtering as the means of instrumentation, specifi¬ 
cally at bn_router again. We begin by making an assumption about connectivity between 
bn_router and bn_server at the network layer. Our instrumentation choice calls for the 
(LINK-FILTER-DSTIP) rule: 

7i9 G {Dbn_router).ifaces[bn_router_ethO].ifUter[dstip\ 

Z ),0 h {p2tC_ switch_ethQe) -/)■ {p2,bn_router_eth0i) 

We discharge our assumptions with the (link-fwd) rule and then complete the derivation 
as we did in the previous attempt. The results are shown in Figure 5 . 12 . 

As expected, a conflict exists in the resulting constraint set. In the negative derivation, we 
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Aj = (p2,bn_router_eth\e) (p2-,bn_server_ethi) 

7 i 9 € {Dbn_router).ifaces[bn_router_ethO].ifilter[dstip] 


Figure 5.12: Second attempt, negative derivation, third scenario 
find the following: 

{D bn_server).ifaces[bn_server_eth] .ipaddr 

G {Dbn_router).ifaces[bn_router_ethO].ifilter[dstip\ 

This contradicts the following constraint generated in the positive derivations: 

{D bn_server).ifaces[bn_server_eth] .ipaddr 

^ {Dbn_router).ifaces[bn_router_ethO].ifilter[dstip] 

We attempt all other derivations using packet filters and forwarding table constraints, and 
we find similar conflicts each time. We must move from here to the transport layer. 


Transport Layer 

The logic offers one option for access control at the transport layer (port filtering at 
the server), so we attempt to use that to complete the derivation. At this level of the 
network stack, our derivation consists of using two rules, (link-filter-dstport) and 
(IRC_PRIVMSG-ENCAP) to reach the final conclusion: 

(TiSj Jii) ^ {Dbn_server).ifaces[bn_server_eth].ifilter[dstport] 

Z ),0 h {s2,c_co_ethe) 74 {s2,bn_server_ethi) 

Z ),0 h {s2,c_co_ethg) 74 {s2,bn_server_ethi) 

Z ),0 h {a2,c_co_ethe) {a2,bn_server_ethi) 

Still, we find a conflict between this and the positive derivations. Our negative derivation 
yields the following constraint: 

(tcp, 6667 ) G {Dbn_server).ifaces[bn_server_eth].ifilter[dstport] 
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This contradicts the following constraint generated in the positive derivations: 


{tcp, 6661 ) ^ {Dbn_server).ifaces[bn_server_eth].ifilter[dstport] 


We have shown that any instrumentation pursuant to a negative outeome ereates a confliet 
with some positive outeome. Speeifieally, any attempt to restriet the eommander’s aceess 
to the IRC service also euts the executive officer’s access, which violates the service-level 
requirements. We therefore fail to generate a satisfiable eonstraint set for this seenario’s 
specified requirements using the given network semanties and logie. In the first two see- 
narios, we saw how the approaeh could be sueeessfully used to provide options for eon- 
straining a network eonfiguration. In this seenario, we see how the approach shows no way 
to generate a satisfiable constraint set. 
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CHAPTER 6: 
Conclusion 


In Chapter 1, we posed five research questions. These questions have guided our thesis 
research, and they are discussed throughout this thesis. We summarize our findings by 
revisiting each of those questions here. 

Can a network’s logical organization be automatically derived based on its physical topol¬ 
ogy and service requirements? We found that, given an understanding of network behavior, 
we could derive the relationships between logical parameters that are required to meet the 
service requirements. There may be multiple derivations, each having a different instantia¬ 
tion of these logical parameters (e.g. number of subnets and VLAN assignments). Which 
derivation we pick can influence network performance. Choosing the best derivation re¬ 
quires knowing how different choices affect performance (e.g. locating a filter close to an 
origin can reduce traffic). While choosing the best derivation is beyond the scope of this 
thesis, we have shown how one can reason about the obligations of a network’s logical 
organization in order to deny access to services for some users while guaranteeing access 
to them for others. This is a major step away from the current practice of first creating a 
logical organization and then hoping it meets access control needs. 

What constitutes a logical organization? Section 3.2 directly addresses this question. We 
realize that a network’s logical organization is a function of the network’s devices and capa¬ 
bilities. For example, if the network includes switches with VLAN capabilities, the logical 
organization will include VLAN assignments for switch ports. Therefore, the parameters 
that constitute a logical organization could become quite large. In this work, we attempt to 
capture the lowest common denominator and provide a basic set of parameters to show the 
service-oriented access control framework’s key concepts. 

What constitutes a network service? This question continues to generate discussion. Dur¬ 
ing our work, we considered the information required to describe the service so that the 
network can properly support it. With that in mind, we can certainly say that a communi¬ 
cation protocol is essential to a network service. In fact, we found that the communication 
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protocol sufficiently describes the network service, at least for our purposes. 

What constitutes a service specification? We found that we could effectively specify a 
service with a sequence of rewrite operations representing messages passed between hosts 
in accordance with a protocol. This sequence of rewrites provides enough information for 
us to constrain a logical organization. A whitepaper [32] provides an example of this. It 
specifies HTTP with a regular expression of rewrites representing TCP and HTTP messages 
sent between a client and a web server. In this work, however, we focus on individual 
rewrite operations. 

How can a network’s logical organization change based on the service specification? Sim¬ 
ply put, a network’s logical organization can change drastically depending on the network’s 
service requirements. As Chapter 5 shows, we had to consider several different options for 
instrumenting the network - and thereby changing the network’s logical organization - 
in order to find a solution that allowed to us achieve both positive and negative service 
requirements. This task became more difficult as the number of requirements increased. 

This thesis describes a logical system that allows us to systematically reason about denying 
movement of a message across a network. The system ensures this for all possible paths 
through the network. The system also provides formal relationships between application- 
layer messages and underlying protocols, thereby bridging the gap between lower-level de¬ 
vice configuration directives and their effects on application-layer messages. It is important 
to note that the system bridges this gap using standards and codified network behavior as 
opposed to experience and industry best practice, which makes this work unique compared 
to other current research efforts, as we discuss in Chapter 2. 

The access control logic was applied in Chapter 5 to realistic scenarios that have relevance 
in the DOD. To achieve this, we use operational experience in building and maintaining 
networks for USMC field artillery battalions. In these scenarios, we also show how our 
approach is ideally suited for small-scale tactical networks with fine-grained security and 
availability requirements. 

It is also important to reiterate that the model (semantics) described in Chapter 3, against 
which the soundness of the access control logic is measured, comes from previous work 
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[32]. The access control logic, which is the primary contribution of this thesis, takes a 
step toward the overall goal of automatic configuration of networks based on service-level 
requirements, both positive and negative. We reproduce the model in this thesis solely for 
the purpose of keeping the thesis self-contained. 

An important issue for discussion in future work is addressing the effect of dynamic events 
on the network’s logical organization. In this thesis, logical organization is assumed not 
to be a function of dynamic events like link or device failure. In reality, however, these 
events can certainly affect logical organization and thereby affect access control. To ad¬ 
dress dynamic changes in physical topology, we envision a system that can detect such 
a topology-changing event, generate and solve a new SOAC instance, and then apply the 
resulting logical organization to the network in response to the event. 

An algorithm should be developed for computing the best derivation in the access control 
logic for a given service. The notion of “best” needs attention. Once addressed, it will also 
guide the algorithm in its search for the best instantiation of logical parameters constrained 
by virtue of the derivation. Ideally, an algorithmic solution will compute a derivation, gen¬ 
erate constraints on the logical organization based on that derivation, try to satisfy those 
constraints, and use a satisfying substitution to configure the network’s devices. A proto¬ 
type algorithm has been written in Prolog, but it makes no attempt to find the best instantia¬ 
tion of constraints. Therefore, we further suggest developing heuristics for guiding such an 
algorithm (e.g., finding the substitution that minimizes traffic flow throughout the network 
or reduces the sizes of forwarding tables). By doing so, a network administrator needs 
only to concern himself with service requirements, letting the SOAC framework optimize 
the network’s performance and ensure its security. Therefore, network complexity can be 
hidden from administrators who need only specify services and their authorized users, not 
the low-level device-specific commands that may collectively achieve this effect. 

The network semantics and access control logic might be extended to capture more device 
capabilities and underlying network protocols. In this work, we focus on a small set of 
devices with a small set of capabilities, and we investigate a small set of services. Future 
work should enlarge these sets so that the SOAC approach can leverage more advanced but 
commonly used technologies like VLAN, virtual private network (VPN), and NAT. Fur¬ 
thermore, future work in this area should focus on prioritizing service requirements. When 


65 



supporting multiple services, network administrators must often make tradeoffs between 
the security and functionality of those various services. This is especially true in tactical 
networks, where bandwidth may be limited and security of certain services may be critical. 
We therefore suggest future work in capturing this notion of priority in leveraging QoS 
technologies to build a priority-sensitive SOAC approach. 


66 



APPENDIX A: 
Network Semantics 


Dh {x,u) ( 3 ;,v) 

(TRANS) D'r {y,v) ^ {z,w) 

D h {x, u) —)■ (z, w) 

switch ^ ipn).type 
p e P 
feF 
f.data = p 

(FRAME-DECAP) 

w G {D n) .if aces 

p.srcip ^ {Dn).ifaces[w\.ifilter[srcip\ 
p.dstip ^ {Dn).ifaces[w].ifilter[dstip] 
if,Wi) {p,Wi) 

switch {Dn).type 
p & P 
feF 
f.data = p 

(frame-encap) w G {Dn).ifaces 

f.srchw = {Dn).ifaces[z].hwaddr 
f.srchw ^ {Dn).ifaces[z].efilter[srchw] 
f.dsthw {Dn).ifaces[z].efilter[dsthw\ 

Dh{p,Ze) {f,Ze) 
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switch G ipn).type 

feF 

XjZE {Dn).if aces 

(SWITCH) 

f.srchw ^ {Dn).ifaces[z].efilter[srchw] 
f.dsthw {Dn).ifaces[z].efilter[dsthw\ 
Dh if, Xi) -y {f,ze) 

switch G {Dn).type 
f^F 

y G {Dm).ifaces[w].direct 
(FRAME-TX-SWITCH-RX) m ^ n 

f.srchw ^ {Dn).ifaces[y\.ifilter[srchw\ 
f.dsthw {Dn).ifaces[y\.ifilter[dsthw\ 
if, We) {f,yi) 

switch f. {Dn).type 

feF 

y G {Dm).ifaces[w].direct 
mfn 

(FRAME-TX-RX) 

f.dsthw = {Dn).ifaces[y].hwaddr 
f.srchw ^ {Dn).ifaces[y\.ifilter[srchw\ 
f.dsthw {Dn).ifaces[y\.ifilter[dsthw\ 
if, We) {f,yi) 
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switch ^ ipn).type 
router ^ {Dn).type 
s eS 

p & p 
p.data = s 

(PACKET-DECAP) 

w G {Dn).if aces 

p.dstip = {Dn).ifaces[w].ipaddr 
{s.protocol^s.srcport) {Dn).ifaces[w\.ifilter[srcport] 

{s.protocol^s.dstport) {Dn).ifaces[w].ifilter[dstport] 

D\- {p,Wi) -y (s,Wi) 

switch {Dn).type 
router {Dn).type 
s es 

p 

p.data = s 
w G {Dn).if aces 

(PACKET-ENCAP) 

{Dn).ifaces[w].netmask = m 
p.dstip & m = {Dn).ifaces[w\.dest 
p.srcip = {Dn).ifaces[w\.ipaddr 
p.srcip ^ {Dn).ifaces[w\.efilter[srcip\ 
p.dstip ^ {Dn).ifaces[w\.efilter[dstip\ 

Dh {s,We) {p,We) 
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router G {Dn).type 
v,w G (Dn).if aces 

V fw 

{Dn).if ace s[w\.net mask = mask 
p & P 

p.dstip ^ 255.255.255.255 

(ROUTER) 

p.dstip f ^mask \ {Dn).ifaces[w].dest 
p.dstip & mask = {pn).ifaces[w\.dest 
{Dn).ifaces[v\.dest 7 ^ {Dn).ifaces[w].dest 
p.srcip ^ {pn).ifaces[w\.efilter[srcip\ 
p.dstip ^ {Dn).ifaces[w].efilter[dstip] 
Dh ^ {p,We) 

server G {Dn).type 
s eS 

a = HTTPS_RQ 

(https_rq-decap) s.data = a 

w G {Dn).if aces 
s.dstport = 443 
Dh ( 5 ,W/) (a.Wi) 

host G {Dn).type 
s es 

a = HTTPS_RQ 
s.data = a 

(HTTPS_RQ-ENCAP) 

w G {Dn).if aces 
s. protocol = tcp 
s.srcport G {Dn). port range 
D h (a, We) -)■ ( 5 , We) 


70 



server G {Dn).type 
s eS 

a = IRC_PRIVMSG 
(IRC_PRIVMSG-DECAP) s.data = a 

w G {Dn).if aces 
s.dstport = 6667 
Dh (5,W/) (a,w,-) 

host G {Dn).type 
s es 

a = IRC_PRIVMSG 
s.data = a 

(IRC_PRIVMSG-ENCAP) 

w G (Dn).if aces 
s. protocol = tcp 
s.srcport G (Dn). port range 
D h (a, We) -)■ {s,We) 
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APPENDIX B: 
Access Control Logic 


host ^ {Dn).type 
f^F 

u G {Dm).if aces 

(LINK-FILTER-SRCHW) 

f.srchw G {Dn).ifaces[v\.ifilter[srchw] 
m^n 

D,A h (/,Me) 7^ (/,v0 

switch^ {Dn).type 
host ^ {Dn).type 
p E P 

(LINK-FILTER-SRCIP) M G {Dm).ifaces 

p.srcip G (D«).z/ace5[v].//z7?pr[5rdj!?] 

D,A h (;?,zze) 74 {p,Vi) 

host {Dn).type 
feF 

u G {Dm).if aces 

(LINK-EILTER-DSTHW) 

f.dsthw G {Dn).ifaces\y\.ifilter[dsthw\ 
mf^n 

D,A h {f,Ue) 74 (/,v,-) 
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(link-filter-dstip) 


(LINK-FILTER-DSTPORT) 


(DEVICE-FILTER-SRCHW) 


(DEVICE-FILTER-SRCIP) 


switch^ ipn).type 
host ^ {Dn).type 
p E P 

u G {Dm).if aces 

p.dstip G {Dn).ifaces[v].ifilter[dstip] 

D,A h {p,Ue) P {p,Vi) 

server G {Dn).type 
seS 

u G {Dm).if aces 

{s.protocofs.dstport) G {Dn).ifaces[v].ifilter[dstport] 
mf^n 

D,A h {s,Ue) -fr (5,V/) 


server {Dn).type 
host {Dn).type 
feF 

M, V G {Dm).if aces 

f.srchw G {Dm).ifaces[v].efilter[srchw] 
D,A h {f,Ui) 74 {f,Ve) 

router E {Dn).type 
p E P 

M, V G {Dm).if aces 

p.srcip G {Dm).ifaces[v].efilter[srcip] 
D,A h {p,Ui) 74 {p,Ve) 


lA 



server ^ {Dn).type 
host ^ {Dn).type 
f^F 

(DEVICE-FILTER-DSTHW) 

M, V G {Dm).if aces 

f.dsthw G {Dm).ifaces[v].efilter[dsthw] 
D,A h {f,Ui) 74 (/,Ve) 

router & {Dn).type 
p e P 

(DEVICE-FILTER-DSTIP) M,vG {Dm).ifaces 

p.dstip G {Dm).ifaces[v].efilter[dstip] 
D,A h 74 (;?,Ve) 


(terminal) 


{Dm).ifaces[u\.direct = {v} 
{Dn).if aces = {v} 

V ^ L 

h 74 


p E P 

u G {Dm).if aces 
p.dstip f {Dn).ifaces[v\.ipaddr 
(IP-ADDRESS) p.dstip 7 ^ 255.255.255.255 
router {Dn).type 
switch ^ {Dn).type 
D,A h {p,Ue) 74 {p,Vi) 
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(SUBNET) 


(LINK-ASSUMPTION) 


(DEVICE-ASSUMPTION) 


(FWD) 


(LINK-FWD) 


(DEVICE-FWD) 


M, V G {Dn).if aces 
p E P 

{Dn).if ace s[v\.net mask = mask 
p.dstip & mask 7 ^ {Dn).ifaces[v].dest 
router^ {Dn).type 
D,A h {p,Ui) 74 {p,Ve) 

(djUg) -fr {d^Vi) gA 
D,A h {d,Ue) 74 (J,v,-) 


(djUi) -fr (J,Vg) GA 

D,A h (J,m,) 74 (J,Ve) 


V G {Dn).if aces 
{Dm).ifaces[u\.direct = {v} 

Vw G {Dn).ifaces — {v}.D,A h {d^Wg) -f- {d^Xi) 
D,A h {d,Ug) 74 {d,Xi) 


V G {Dn).if aces 
{Dm).ifaces[u\.direct = {v} 

Vw G {Dn).ifaces — {v}.D,AU 5 h {d,We) -ft {d,Xi) 
D,A h {d,Ug) -fr {d,Vi) 

D,A h {d,Ug) 74 {d,Xi) 


V G {Dn).if aces 
{Dm).ifaces[u\.direct = {v} 

Vw G {Dn).ifaces — {v}.D,AU5 h {d,We) -ft {d,Xi) 
Vw G {Dn).ifaces — {v}.D,A\- {d,Vi) -fr {d^Wg) 
D,A h {d,Ug) 74 {d,Xi) 
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(https_rq-encap) 


s eS 

s.data = a 
a = HTTPS_RQ 

D,A h {s,Ue) 74 (^,V;) 
D,A h (a, Me) 74 {a, Vi) 


s es 

s.data = a 

(IRC_PRIVMSG-ENCAP) a = IRC_PRIVMSG 

D,A h {s,Ue) 74 (^,V;) 
D,A h (a, Me) 74 {a, Vi) 

p & P 
p.data = s 

(SEG-ENCAP) 

h {p,Ue) 74 (pAi) 

D,A h (5, Me) 74 ( 5 ,V,) 


(PKT-ENCAP) 


f^F 

f.data = p 

D,A h (/,Me) 74 (/,V,-) 
h (;?,Me) 74 {pAi) 
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